From alessiostalla at gmail.com  Wed Oct 26 17:12:41 2011
From: alessiostalla at gmail.com (Alessio Stalla)
Date: Wed, 26 Oct 2011 19:12:41 +0200
Subject: [fset-devel] FSet on ABCL
Message-ID: <CAL2Kp+h89JgA36oQFkDuWUpk61v85GvSXSJoXooytvMRHhtJJA@mail.gmail.com>

Greetings,

as part of my nth plan to conquer the world (which of course I won't
unveil right now), I tried FSet on ABCL. I managed to make it run, but
I had to patch it; you can find the patch attached (it's taken against
the version in Quicklisp, but I believe it's the latest version).

Besides some minor #+abcl porting stuff, the one thing that stuck out
was the DEFLEX macro for defining global lexical variables, which
conflicts with ABCL's implementation of symbol macros.
(deflex var) expands basically into (define-symbol-macro var
(symbol-value 'var)). The problem: ABCL stores symbol macros in the
value cell of symbols, so you can't have a symbol which is both a
variable and a symbol macro.
Now, I believe deflex as written is non portable CL. This is because
accessing the symbol-value of an unbound variable is, to my
interpretation, unspecified [*]; and if you use defvar/defparameter
with var, then you cannot use it as a symbol macro. Thus, I patched it
(taking inspiration from Rob Warnock's version of deflex/defglobal).
However, I do think ABCL's implementation is very brittle (and
probably conflicting with ANSI as well), because if you setf the
symbol-value of a symbol with a global symbol macro attached, you
remove the symbol macro! So, I think we should fix it for 1.0.1.
Perhaps I can do the fix myself, but we better discuss it before
because I fear this might be a deep change.


[*] symbol-value ... Accesses the symbol's value cell. [1]
value cell n. Trad. (of a symbol) The place which holds the value, if
any, of the dynamic variable named by that symbol, and which is
accessed by symbol-value. [2]
dynamic variable n. a variable the binding for which is in the dynamic
environment. [3]

I don't think a symbol for which there is no special declaration in
scope can be considered to name a dynamic variable, and thus to have a
value cell at all.

[1] http://www.lispworks.com/documentation/HyperSpec/Body/f_symb_5.htm#symbol-value
[2] http://www.lispworks.com/documentation/HyperSpec/Body/26_glo_v.htm#value_cell
[3] http://www.lispworks.com/documentation/HyperSpec/Body/26_glo_d.htm#dynamic_variable

Cheers,
Alessio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fset.abcl.patch
Type: application/octet-stream
Size: 3514 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/fset-devel/attachments/20111026/e4e1e39f/attachment.obj>

From Scott at sympoiesis.com  Wed Oct 26 21:41:58 2011
From: Scott at sympoiesis.com (Scott L. Burson)
Date: Wed, 26 Oct 2011 14:41:58 -0700
Subject: [fset-devel] FSet on ABCL
In-Reply-To: <CAL2Kp+h89JgA36oQFkDuWUpk61v85GvSXSJoXooytvMRHhtJJA@mail.gmail.com>
References: <CAL2Kp+h89JgA36oQFkDuWUpk61v85GvSXSJoXooytvMRHhtJJA@mail.gmail.com>
Message-ID: <CAF5LJ4AfZL_nCGgjDOortT-9r_daudyXx0s8-kSe_49PrTzvuQ@mail.gmail.com>

On Wed, Oct 26, 2011 at 10:12 AM, Alessio Stalla
<alessiostalla at gmail.com> wrote:
> Greetings,
>
> as part of my nth plan to conquer the world (which of course I won't
> unveil right now), I tried FSet on ABCL. I managed to make it run, but
> I had to patch it; you can find the patch attached (it's taken against
> the version in Quicklisp, but I believe it's the latest version).

Thanks for the patch!

Did you run the test suite?  Were any non-default JVM settings
required, e.g. stack size?

Do you have any performance comparisons (of FSet operations in
particular) vis-a-vis, say, SBCL?

> Besides some minor #+abcl porting stuff, the one thing that stuck out
> was the DEFLEX macro for defining global lexical variables, which
> conflicts with ABCL's implementation of symbol macros.
> (deflex var) expands basically into (define-symbol-macro var
> (symbol-value 'var)). The problem: ABCL stores symbol macros in the
> value cell of symbols, so you can't have a symbol which is both a
> variable and a symbol macro.
> Now, I believe deflex as written is non portable CL. This is because
> accessing the symbol-value of an unbound variable is, to my
> interpretation, unspecified [*]; and if you use defvar/defparameter
> with var, then you cannot use it as a symbol macro. Thus, I patched it
> (taking inspiration from Rob Warnock's version of deflex/defglobal).

Heh -- I had seen Rob's implementation and wondered why he created a
second symbol.  Now I know :-)

> I don't think a symbol for which there is no special declaration in
> scope can be considered to name a dynamic variable, and thus to have a
> value cell at all.

On a strict reading, you're probably correct.  But I had never seen an
implementation for which this was not the case.

-- Scott



From alessiostalla at gmail.com  Wed Oct 26 23:19:30 2011
From: alessiostalla at gmail.com (Alessio Stalla)
Date: Thu, 27 Oct 2011 01:19:30 +0200
Subject: [fset-devel] FSet on ABCL
In-Reply-To: <CAF5LJ4AfZL_nCGgjDOortT-9r_daudyXx0s8-kSe_49PrTzvuQ@mail.gmail.com>
References: <CAL2Kp+h89JgA36oQFkDuWUpk61v85GvSXSJoXooytvMRHhtJJA@mail.gmail.com>
	<CAF5LJ4AfZL_nCGgjDOortT-9r_daudyXx0s8-kSe_49PrTzvuQ@mail.gmail.com>
Message-ID: <CAL2Kp+ie=-OKu8oecFG1UNDqCs0nZD0fjsbqAibxs0s_d62oTQ@mail.gmail.com>

On Wed, Oct 26, 2011 at 11:41 PM, Scott L. Burson <Scott at sympoiesis.com> wrote:
> On Wed, Oct 26, 2011 at 10:12 AM, Alessio Stalla
> <alessiostalla at gmail.com> wrote:
>> Greetings,
>>
>> as part of my nth plan to conquer the world (which of course I won't
>> unveil right now), I tried FSet on ABCL. I managed to make it run, but
>> I had to patch it; you can find the patch attached (it's taken against
>> the version in Quicklisp, but I believe it's the latest version).
>
> Thanks for the patch!
>
> Did you run the test suite? ?Were any non-default JVM settings
> required, e.g. stack size?
>
> Do you have any performance comparisons (of FSet operations in
> particular) vis-a-vis, say, SBCL?

I haven't run the test suite yet, nor made any performance
comparisons. Regarding JVM settings, in order to compile and load FSet
(under SLIME) I had to increase the maximum heap size from the (iirc)
64M default. I set it at 256M but it may well be that a lower value is
sufficient. In the next few days I'll do a few tests and benchmarks
and I'll keep you informed on the results.

>
>> Besides some minor #+abcl porting stuff, the one thing that stuck out
>> was the DEFLEX macro for defining global lexical variables, which
>> conflicts with ABCL's implementation of symbol macros.
>> (deflex var) expands basically into (define-symbol-macro var
>> (symbol-value 'var)). The problem: ABCL stores symbol macros in the
>> value cell of symbols, so you can't have a symbol which is both a
>> variable and a symbol macro.
>> Now, I believe deflex as written is non portable CL. This is because
>> accessing the symbol-value of an unbound variable is, to my
>> interpretation, unspecified [*]; and if you use defvar/defparameter
>> with var, then you cannot use it as a symbol macro. Thus, I patched it
>> (taking inspiration from Rob Warnock's version of deflex/defglobal).
>
> Heh -- I had seen Rob's implementation and wondered why he created a
> second symbol. ?Now I know :-)

I don't particularly like the second interned symbol solution... I
tried initially with a gensym, but it's hard to get right the
interplay between compile-time, load time, and the file compiler
possibly losing gensym identity, so I guess Rob's approach is the most
practical.

>
>> I don't think a symbol for which there is no special declaration in
>> scope can be considered to name a dynamic variable, and thus to have a
>> value cell at all.
>
> On a strict reading, you're probably correct. ?But I had never seen an
> implementation for which this was not the case.

Yes, me neither, and I'd like to get ABCL fixed in that regard. You
might keep your implementation of deflex as-is; in the meantime I will
use my patched version, until ABCL is fixed.

Thanks,
Alessio



From joshuaaaron at gmail.com  Wed Oct 26 22:48:13 2011
From: joshuaaaron at gmail.com (Joshua TAYLOR)
Date: Wed, 26 Oct 2011 18:48:13 -0400
Subject: [fset-devel] FSet on ABCL
In-Reply-To: <CAF5LJ4AfZL_nCGgjDOortT-9r_daudyXx0s8-kSe_49PrTzvuQ@mail.gmail.com>
References: <CAL2Kp+h89JgA36oQFkDuWUpk61v85GvSXSJoXooytvMRHhtJJA@mail.gmail.com>
	<CAF5LJ4AfZL_nCGgjDOortT-9r_daudyXx0s8-kSe_49PrTzvuQ@mail.gmail.com>
Message-ID: <CA+Q4Jnk6_4TFL-GXsh2M_7FvOLqYLjDT2qiiDSy6ey9Ev9MkVw@mail.gmail.com>

On Wed, Oct 26, 2011 at 5:41 PM, Scott L. Burson <Scott at sympoiesis.com> wrote:
> On Wed, Oct 26, 2011 at 10:12 AM, Alessio Stalla
> <alessiostalla at gmail.com> wrote:
>> I don't think a symbol for which there is no special declaration in
>> scope can be considered to name a dynamic variable, and thus to have a
>> value cell at all.
>
> On a strict reading, you're probably correct. ?But I had never seen an
> implementation for which this was not the case.

I'm not sure a strict reading would have that. Symbols can have value
attributes, and value attributes are accessed by symbol-value [1]:
"If a symbol has a value attribute, it is said to be bound, and that
fact can be detected by the function boundp. The object contained in
the value cell of a bound symbol is the value of the global variable
named by that symbol, and can be accessed by the function
symbol-value. A symbol can be made to be unbound by the function
makunbound."

Symbol-value [2] accesses a symbol's value attribute, and it's
explicitly mentioned that unbound issues only occur on reads:
"Should signal unbound-variable if symbol is unbound and an attempt is
made to read its value. (No such error is signaled on an attempt to
write its value.) "
I'd think, then, that as long as some symbol-value is written first,
reading shouldn't be a problem.

The issue with symbol-macros and special variables still stands of
course.  But I don't think that a symbol needs to be declared as a
special variable in order for its symbol-value to be set and read.

//JT

[1] http://www.lispworks.com/documentation/HyperSpec/Body/t_symbol.htm#symbol
[2] http://www.lispworks.com/documentation/HyperSpec/Body/f_symb_5.htm#symbol-value

-- 
Joshua Taylor, http://www.cs.rpi.edu/~tayloj/