I have 3 enviroment to run LISP
Linux and CLISP
Windows and CLISP
OS/X and SBCL
On SBCL
a get a warning that a variabel is not defined when a do a
(setq x 10)
it is a WARNING and it sets x = 10
If i do the same on CLISP i get no warning
Anyone can tell me way and sould i not use SETQ to enter new
variabels / Konstant
my LISP book says this is the way soo.
// Anders
anders <················@gmail.com> wrote on Sat, 02 Jun 2007:
> On SBCL a get a warning that a variabel is not defined when a do a
> (setq x 10)
> it is a WARNING and it sets x = 10
> If i do the same on CLISP i get no warning
That code, as is, is not portable ANSI CL. Because you haven't yet declared
x to be a special variable, but you're using it that way.
The implementations are being nice to you, by giving you what you mean,
even if you didn't express it as required. SBCL has chosen to warn you
that you aren't writing strict ANSI CL.
> Anyone can tell me way and sould i not use SETQ to enter new
> variabels / Konstant
> my LISP book says this is the way soo.
(defparameter x 10)
should get you the behavior you expect (in every implementation), without the
warnings.
After you do that once, you can then do
(setq x 20)
and you shouldn't get warnings either.
If you get curious, you might also want to compare with DEFVAR and
DEFCONSTANT, both of which do similar things but with minor variations.
Also, as a style warning, most Lisp programmers put asterixes around the
names of global variables, just as a visual clue, so you might want
(defparameter *x* 10)
(setq *x* 20)
instead.
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
The first thing was, I learned to forgive myself. Then, I told myself, "Go
ahead and do whatever you want, it's okay by me."
-- Deep Thoughts, by Jack Handey [1999]
In article <··············@yoda.geddis.org>,
Don Geddis <···@geddis.org> wrote:
> anders <················@gmail.com> wrote on Sat, 02 Jun 2007:
> > On SBCL a get a warning that a variabel is not defined when a do a
> > (setq x 10)
> > it is a WARNING and it sets x = 10
> > If i do the same on CLISP i get no warning
>
> That code, as is, is not portable ANSI CL. Because you haven't yet declared
> x to be a special variable, but you're using it that way.
He wants to use it as a global variable.
>
> The implementations are being nice to you, by giving you what you mean,
> even if you didn't express it as required. SBCL has chosen to warn you
> that you aren't writing strict ANSI CL.
Actually most implementations are even nicer.
If you do by accident (setq x ...) you don't want x to be defined
special. So most implementations don't do that. Only CMUCL
did (does?) it - and I hated it. The problem is that
it is not easy to remove the effects of declaring a variable
special.
I've never understood why there are no non-special
global variables in ANSI Common Lisp. Introducing a global
variable in Common Lisp automatically means that
ALL local variables of that name are special, too.
Warning: Skip the next if too advanced:
It creates lots of interesting behaviour:
(defvar y 1)
We have a global special variable y.
(defun x (y)
(lambda ()
(+ y 1.0)))
++++ Trap 1 ++++
We define a function that looks like it is returning a closure.
But it does not!!! If Y would not have been DEFVARed, it
would be a closure. But it isn't.
(defparameter foo (x 2))
foo has a function as its value, but not a closure!
(funcall foo)
Above returns 2.0. the global y = 1 plus 1.0.
++++ Trap 2 ++++
See this:
((lambda (y)
(funcall foo))
3)
which is the same as:
(funcall (function (lambda (y)
(funcall foo)))
3)
Which is the same as:
(let ((y 3))
(funcall foo))
The above forms return 4.0! So we have dynamic binding via function
parameters!!
++++ STYLE ADVICE ++++
So, NEVER EVER define a global without 'asterixes'.
It might interfere with your other code and create
STRANGE effects.
>
> > Anyone can tell me way and sould i not use SETQ to enter new
> > variabels / Konstant
> > my LISP book says this is the way soo.
>
> (defparameter x 10)
> should get you the behavior you expect (in every implementation), without the
> warnings.
>
> After you do that once, you can then do
> (setq x 20)
> and you shouldn't get warnings either.
>
> If you get curious, you might also want to compare with DEFVAR and
> DEFCONSTANT, both of which do similar things but with minor variations.
>
> Also, as a style warning, most Lisp programmers put asterixes around the
> names of global variables, just as a visual clue, so you might want
> (defparameter *x* 10)
> (setq *x* 20)
> instead.
+and-this-is-a-constant+
>
> -- Don
> _______________________________________________________________________________
> Don Geddis http://don.geddis.org/ ···@geddis.org
> The first thing was, I learned to forgive myself. Then, I told myself, "Go
> ahead and do whatever you want, it's okay by me."
> -- Deep Thoughts, by Jack Handey [1999]
--
http://lispm.dyndns.org
Rainer Joswig <······@lisp.de> writes:
> ++++ STYLE ADVICE ++++
>
> So, NEVER EVER define a global without 'asterixes'.
> It might interfere with your other code and create
> STRANGE effects.
>
Or use the very useful and more "unharmful" deflex (thanks to Rob
Warnock[1]):
(defmacro deflex (var val &optional (doc nil docp))
(let ((backing-var (intern (concatenate 'string
(symbol-name '#:*deflex-var-)
(symbol-name var)
(symbol-name '#:*))
(symbol-package var))))
`(progn
(defparameter ,backing-var ,val ,doc)
,@(when docp `((setf (documentation ',var 'variable) ,doc)))
(define-symbol-macro ,var ,backing-var))))
Footnotes:
[1] ··········································································@speakeasy.net
In article <··············@matley.muppetslab.org>,
Luigi Panzeri <······@muppetslab.org> wrote:
> Rainer Joswig <······@lisp.de> writes:
>
> > ++++ STYLE ADVICE ++++
> >
> > So, NEVER EVER define a global without 'asterixes'.
> > It might interfere with your other code and create
> > STRANGE effects.
> >
>
>
> Or use the very useful and more "unharmful" deflex (thanks to Rob
> Warnock[1]):
>
> (defmacro deflex (var val &optional (doc nil docp))
> (let ((backing-var (intern (concatenate 'string
> (symbol-name '#:*deflex-var-)
> (symbol-name var)
> (symbol-name '#:*))
> (symbol-package var))))
> `(progn
> (defparameter ,backing-var ,val ,doc)
> ,@(when docp `((setf (documentation ',var 'variable) ,doc)))
> (define-symbol-macro ,var ,backing-var))))
>
>
> Footnotes:
> [1] ··········································································@speakeasy.net
Haven't tried it out, yet. Thanks for mentioning it!
Something like that should be in the language, IMHO.
--
http://lispm.dyndns.org
On Sat, 02 Jun 2007 23:41:45 +0200, Rainer Joswig <······@lisp.de> said:
| ...
| Something like that should be in the language, IMHO.
The quality of global lexicals is not strained,
It droppeth like the gentle rain from heaven
Upon the REPL beneath...
(With apologies to the Globe Hacker.)
---Vassil.
--
The truly good code is the obviously correct code.
(message (Hello 'Rainer)
(you :wrote :on '(Sat, 02 Jun 2007 22:36:10 +0200))
(
RJ> I've never understood why there are no non-special
RJ> global variables in ANSI Common Lisp. Introducing a global
RJ> variable in Common Lisp automatically means that
RJ> ALL local variables of that name are special, too.
indeed it's very strange, since even without ambiguous toplevel SETQ it's
possible to make non-special global variables in most (all?)
implementations -- either proclaiming variable locally special, or via
symbol's value.
as spec says, symbol's value is closely related to the global variable
value -- they are same if variable is special. but most implementation also
use symbol's value as variable value if variable is not special and is not
lexical.
so i wonder why this behaviour was not standartized (if it's already present
in most implementations), and instead of this DEFINE-SYMBOL-MACRO is
proposed for "global lexicals" in issue ISO-COMPATIBILITY (ISLISP appears to
have global lexicals built-in?) -- as for me, it's a bit counter-intuitive
that SYMBOL-MACRO can be shadowed by LET, but works with SETQ trasparently.
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"I am everything you want and I am everything you need")
On Sun, 3 Jun 2007 00:14:52 +0300, "Alex Mizrahi" <········@users.sourceforge.net> said:
| (message (Hello 'Rainer)
| (you :wrote :on '(Sat, 02 Jun 2007 22:36:10 +0200))
| (
RJ| I've never understood why there are no non-special
RJ| global variables in ANSI Common Lisp. Introducing a global
RJ| variable in Common Lisp automatically means that
RJ| ALL local variables of that name are special, too.
| indeed it's very strange, since even without ambiguous toplevel SETQ it's
| possible to make non-special global variables in most (all?)
| implementations -- either proclaiming variable locally special, or via
| symbol's value.
| as spec says, symbol's value is closely related to the global variable
| value -- they are same if variable is special. but most implementation also
| use symbol's value as variable value if variable is not special and is not
| lexical.
Now, what kind of variable would that be? Actually, which language
do you have in mind here?
| so i wonder why this behaviour was not standartized (if it's already present
| in most implementations), and instead of this DEFINE-SYMBOL-MACRO is
| proposed for "global lexicals" in issue ISO-COMPATIBILITY (ISLISP appears to
| have global lexicals built-in?) -- as for me, it's a bit counter-intuitive
| that SYMBOL-MACRO can be shadowed by LET, but works with SETQ trasparently.
True global lexicals go together with an EVAL that takes two
arguments. It is not for nothing that there are multiple languages
in the Lisp family.
---Vassil.
--
The truly good code is the obviously correct code.
Rainer Joswig <······@lisp.de> writes:
> I've never understood why there are no non-special
> global variables in ANSI Common Lisp. Introducing a global
> variable in Common Lisp automatically means that
> ALL local variables of that name are special, too.
There was a proposal for lexical declarations that would have included
global lexical variables [1]. AFAICT, there were many subtleties
invloved and not enough established practice.
[1] http://www.nhplace.com/kent/CL/Issues/proclaim-lexical.html
Richard M Kreuter wrote:
> Rainer Joswig <······@lisp.de> writes:
>
>> I've never understood why there are no non-special
>> global variables in ANSI Common Lisp. Introducing a global
>> variable in Common Lisp automatically means that
>> ALL local variables of that name are special, too.
>
> There was a proposal for lexical declarations that would have included
> global lexical variables [1]. AFAICT, there were many subtleties
> invloved and not enough established practice.
>
> [1] http://www.nhplace.com/kent/CL/Issues/proclaim-lexical.html
The underlying issue is that lexical and special variables share the
same namespace: Whenever you mention a symbol in an for-evaluation
position, it may be a lexical or a special variable. This means that as
soon as you a variable is free, it is ambiguous whether you mean a
potential special variable or a global lexical variable.
ISLISP solved this issue by strictly separating the lexical and the
special variable namespaces. There, the only way to refer to a special
binding is by saying (dynamic var-name). If a symbol is mentioned in a
for-evaluation position, it is always a lexical one, which includes
potential global lexical variables.
Fortunately, define-symbol-macro allows expressing a workaround in
Common Lisp that's good enough.
I wonder whether the following would be good enough:
(define-symbol-macro var (symbol-value 'var))
...or as a higher-order macro:
(defmacro defglobal (name expression)
`(progn
(define-symbol-macro ,name (symbol-value ',name))
(setf (symbol-value ',name) ,expression)
',name))
?
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza <··@p-cos.net> writes:
> I wonder whether the following would be good enough:
>
> (define-symbol-macro var (symbol-value 'var))
>
> ...or as a higher-order macro:
>
> (defmacro defglobal (name expression)
> `(progn
> (define-symbol-macro ,name (symbol-value ',name))
> (setf (symbol-value ',name) ,expression)
> ',name))
>
> ?
Not quite: this approach doesn't prevent somebody from accidentally
dynamically rebinding the variable named NAME, which wouldn't be
possible if the variable were really lexical. Consider things without
the symbol-macro:
> (defun some-function () (symbol-value 'some-symbol))
SOME-FUNCTION
> (setf (symbol-value 'some-symbol) 100)
100
> (some-function)
100
> (let ((some-symbol 10))
(declare (special some-symbol))
(some-function))
10
Putting the value on the symbol's plist would do slightly better, but
would be prone to the same sort of failure if the implementation
supported binding of the symbol plist or of a place on the plist.
Additionally, IIUC, it was a goal of the failed proposal to permit
local scope declarations to override global scope proclamations, so
that you could say things like
(proclaim '(special x))
(locally (declare (lexical x))
(defun foo () x))
You can't simulate that effect with symbol-macros alone, since an
error is signalled when trying to establish a symbol macro for a
symbol that's already defined as a global variable. (Having special
and lexical variables with the same name is a bad idea anyhow, so this
is probably a minor issue for people who care about lexical
variables.)
On Jun 3, 4:09 pm, Richard M Kreuter <·······@progn.net> wrote:
[...]
> Putting the value on the symbol's plist would do slightly better, but
> would be prone to the same sort of failure if the implementation
> supported binding of the symbol plist or of a place on the plist.
Here's one solution to that:
(defmacro deflex (var val)
(let ((backing (gensym)))
`(progn
(setf (symbol-value ',backing) val)
(define-symbol-macro ,var (symbol-value ',backing))))
There are any number of possibilities where you set up some sort of
data structure to hold the value you want in the "global lexical".
It doesn't solve the other problem, though.
Cheers,
Pillsy
Pillsy <·········@gmail.com> writes:
> On Jun 3, 4:09 pm, Richard M Kreuter <·······@progn.net> wrote:
> [...]
>> Putting the value on the symbol's plist would do slightly better, but
>> would be prone to the same sort of failure if the implementation
>> supported binding of the symbol plist or of a place on the plist.
>
> Here's one solution to that:
>
> (defmacro deflex (var val)
> (let ((backing (gensym)))
> `(progn
> (setf (symbol-value ',backing) val)
> (define-symbol-macro ,var (symbol-value ',backing))))
This is different from the previous two proposals: repeated evaluation
of such a deflex creates a fresh value cell, with the result that what
looks like the same variable in different places can be associated
with different value cells.
> (deflex abc 5)
ABC
> abc
5
> (defun some-fun ()
abc)
SOME-FUN
> (some-fun)
5
> (deflex abc 10)
ABC
> abc
10
> (defun more-fun ()
abc)
MORE-FUN
> (more-fun)
10
> (some-fun)
5
--
RmK
Richard M Kreuter <·······@progn.net> wrote:
+---------------
| Pillsy <·········@gmail.com> writes:
| > (defmacro deflex (var val)
| > (let ((backing (gensym)))
| > `(progn
| > (setf (symbol-value ',backing) val)
| > (define-symbol-macro ,var (symbol-value ',backing))))
|
| This is different from the previous two proposals: repeated evaluation
| of such a deflex creates a fresh value cell, with the result that what
| looks like the same variable in different places can be associated
| with different value cells.
+---------------
Yes, that's one of the reasons that my version of DEFLEX [posted
a couple of weeks ago] creates the backing vauable deterministicly
from the name of the first DEFLEX arg, so you always get the same
value cell each time.
Another reason is that if you happen to MACROEXPAND some code
that references a DEFLEX'd variable, you're not left *totally*
clueless about where the code came from, e.g.:
> (deflex abc 5)
ABC
> (macroexpand 'abc)
*STORAGE-FOR-DEFLEX-VAR-ABC*
T
>
And it plays well with DESCRIBE, too:
> (describe 'abc)
ABC is an internal symbol in the COMMON-LISP-USER package.
It is a symbol macro with expansion: *STORAGE-FOR-DEFLEX-VAR-ABC*.
>
+---------------
| > (deflex abc 5)
| ABC
| > abc
| 5
| > (defun some-fun () abc)
| SOME-FUN
| > (some-fun)
| 5
| > (deflex abc 10)
| ABC
| > abc
| 10
| > (defun more-fun () abc)
| MORE-FUN
| > (more-fun)
| 10
| > (some-fun)
| 5
+---------------
Whereas with my version the final (SOME-FUN) also returns 10.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
In article <···············@mid.individual.net>,
Pascal Costanza <··@p-cos.net> wrote:
> Richard M Kreuter wrote:
> > Rainer Joswig <······@lisp.de> writes:
> >
> >> I've never understood why there are no non-special
> >> global variables in ANSI Common Lisp. Introducing a global
> >> variable in Common Lisp automatically means that
> >> ALL local variables of that name are special, too.
> >
> > There was a proposal for lexical declarations that would have included
> > global lexical variables [1]. AFAICT, there were many subtleties
> > invloved and not enough established practice.
> >
> > [1] http://www.nhplace.com/kent/CL/Issues/proclaim-lexical.html
>
> The underlying issue is that lexical and special variables share the
> same namespace: Whenever you mention a symbol in an for-evaluation
> position, it may be a lexical or a special variable. This means that as
> soon as you a variable is free, it is ambiguous whether you mean a
> potential special variable or a global lexical variable.
There are a lot of things that are ambiguous in CL when
not defined upfront (DEFMETHOD vs. DEFGENERIC+DEFMETHOD).
Somehow I think that all variables should be lexical,
unless declared otherwise. Possible confusion
should be reduced as much as possible.
Yes, that would break lots of existing code.
Practice in most implementations is:
* undefined (no DEFVAR / DEFPARAMETER) global variables
are not automatically defined special
* undefined variables in functions are treated as being locally
defined as special
Is that right?
>
> ISLISP solved this issue by strictly separating the lexical and the
> special variable namespaces. There, the only way to refer to a special
> binding is by saying (dynamic var-name). If a symbol is mentioned in a
> for-evaluation position, it is always a lexical one, which includes
> potential global lexical variables.
>
> Fortunately, define-symbol-macro allows expressing a workaround in
> Common Lisp that's good enough.
>
> I wonder whether the following would be good enough:
>
> (define-symbol-macro var (symbol-value 'var))
>
> ...or as a higher-order macro:
>
> (defmacro defglobal (name expression)
> `(progn
> (define-symbol-macro ,name (symbol-value ',name))
> (setf (symbol-value ',name) ,expression)
> ',name))
>
> ?
>
> Pascal
--
http://lispm.dyndns.org
Rainer Joswig wrote:
> In article <···············@mid.individual.net>,
> Pascal Costanza <··@p-cos.net> wrote:
>
>> Richard M Kreuter wrote:
>>> Rainer Joswig <······@lisp.de> writes:
>>>
>>>> I've never understood why there are no non-special
>>>> global variables in ANSI Common Lisp. Introducing a global
>>>> variable in Common Lisp automatically means that
>>>> ALL local variables of that name are special, too.
>>> There was a proposal for lexical declarations that would have included
>>> global lexical variables [1]. AFAICT, there were many subtleties
>>> invloved and not enough established practice.
>>>
>>> [1] http://www.nhplace.com/kent/CL/Issues/proclaim-lexical.html
>> The underlying issue is that lexical and special variables share the
>> same namespace: Whenever you mention a symbol in an for-evaluation
>> position, it may be a lexical or a special variable. This means that as
>> soon as you a variable is free, it is ambiguous whether you mean a
>> potential special variable or a global lexical variable.
>
> There are a lot of things that are ambiguous in CL when
> not defined upfront (DEFMETHOD vs. DEFGENERIC+DEFMETHOD).
>
> Somehow I think that all variables should be lexical,
> unless declared otherwise. Possible confusion
> should be reduced as much as possible.
> Yes, that would break lots of existing code.
>
> Practice in most implementations is:
>
> * undefined (no DEFVAR / DEFPARAMETER) global variables
> are not automatically defined special
>
> * undefined variables in functions are treated as being locally
> defined as special
>
> Is that right?
Yes, although I am pretty convinced that the second bullet is not
because it is considered to be a good idea that free variables are
special. However, currently the only way for a free variable to make
sense is when it eventually ends up being a special variable, because
the only way to introduce a global variable, and thus to provide a
binding for a free variable, is to make it special.
If global lexical variables were added to the mix, I would assume that
that default would change.
Theoretically. ;)
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
In article <···············@mid.individual.net>,
Pascal Costanza <··@p-cos.net> wrote:
> Rainer Joswig wrote:
> > In article <···············@mid.individual.net>,
> > Pascal Costanza <··@p-cos.net> wrote:
> >
> >> Richard M Kreuter wrote:
> >>> Rainer Joswig <······@lisp.de> writes:
> >>>
> >>>> I've never understood why there are no non-special
> >>>> global variables in ANSI Common Lisp. Introducing a global
> >>>> variable in Common Lisp automatically means that
> >>>> ALL local variables of that name are special, too.
> >>> There was a proposal for lexical declarations that would have included
> >>> global lexical variables [1]. AFAICT, there were many subtleties
> >>> invloved and not enough established practice.
> >>>
> >>> [1] http://www.nhplace.com/kent/CL/Issues/proclaim-lexical.html
> >> The underlying issue is that lexical and special variables share the
> >> same namespace: Whenever you mention a symbol in an for-evaluation
> >> position, it may be a lexical or a special variable. This means that as
> >> soon as you a variable is free, it is ambiguous whether you mean a
> >> potential special variable or a global lexical variable.
> >
> > There are a lot of things that are ambiguous in CL when
> > not defined upfront (DEFMETHOD vs. DEFGENERIC+DEFMETHOD).
> >
> > Somehow I think that all variables should be lexical,
> > unless declared otherwise. Possible confusion
> > should be reduced as much as possible.
> > Yes, that would break lots of existing code.
> >
> > Practice in most implementations is:
> >
> > * undefined (no DEFVAR / DEFPARAMETER) global variables
> > are not automatically defined special
> >
> > * undefined variables in functions are treated as being locally
> > defined as special
> >
> > Is that right?
>
> Yes, although I am pretty convinced that the second bullet is not
> because it is considered to be a good idea that free variables are
> special. However, currently the only way for a free variable to make
> sense is when it eventually ends up being a special variable, because
> the only way to introduce a global variable, and thus to provide a
> binding for a free variable, is to make it special.
That's what the standard says.
In practice I can write at the top-level (setq bar 'foo)
and I have a global non-special variable.
Since any symbol has a value cell,
any form that introduces a symbol also introduces a value cell.
So any free variable bar could just point to the value
cell of the symbol bar, without any special declaration.
Not sure if that is right, though...
>
> If global lexical variables were added to the mix, I would assume that
> that default would change.
>
> Theoretically. ;)
>
>
> Pascal
--
http://lispm.dyndns.org
On Sun, 03 Jun 2007 19:08:42 +0200, Rainer Joswig <······@lisp.de> said:
| ...
| In practice I can write at the top-level (setq bar 'foo)
| and I have a global non-special variable.
Assuming, for the sake of argument, that the above was well-defined,
it _would_ be special (because (SYMBOL-VALUE 'BAR) => FOO) in Common
Lisp, it just would not be proclaimed special.
| Since any symbol has a value cell,
| any form that introduces a symbol also introduces a value cell.
Not if the form introduces the symbol with a lexical binding (and if
"value cell" here means the cell for which SYMBOL-VALUE is the
accessor).
---Vassil.
--
The truly good code is the obviously correct code.
Rainer Joswig <······@lisp.de> writes:
> In article <···············@mid.individual.net>,
> Pascal Costanza <··@p-cos.net> wrote:
>
>> Rainer Joswig wrote:
> In practice I can write at the top-level (setq bar 'foo)
> and I have a global non-special variable.
That's backwards; what you really have is a non-global special
(in practice - most CLs do the special declaration). It's not global,
not only in the sense that it wasn't declared with proclaim or
declaim, but also because another binding of the same name does not
take on the special-ness of 'bar assumed in the free reference. I
don't know what other CLs call it, but in Allegro CL, we make the
distinction between "special" and "globaly-special" for clarity of
thinking.
> Since any symbol has a value cell,
> any form that introduces a symbol also introduces a value cell.
> So any free variable bar could just point to the value
> cell of the symbol bar, without any special declaration.
>
> Not sure if that is right, though...
But remember that the compiler might take a lexical usage of this
symbol (as a name) and compile it away:
(defun foo (bar)
(bas bar))
This isn't a free variable, but it is the same one as had been used in
a free reference. But when you then load the fasl file into another
instance of the lisp, bar doesn't exist, but the compiled location
(presumably on the stack) does exist, and (as in the original
compiling lisp) the value of the variable is not a value cell, but
something else.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig <·····@franz.com> writes:
> Rainer Joswig <······@lisp.de> writes:
>
> > In practice I can write at the top-level (setq bar 'foo)
> > and I have a global non-special variable.
>
> That's backwards; what you really have is a non-global special
> (in practice - most CLs do the special declaration). It's not global,
> not only in the sense that it wasn't declared with proclaim or
> declaim, but also because another binding of the same name does not
> take on the special-ness of 'bar assumed in the free reference.
This is actually implementation-specific behavior. Most lisp
implementations that I know of work the way Duane Rettig describes. For
example, Allegro, LispWorks, MCL and OpenMCL. However, CMUCL in its
default configuration does, indeed, proclaim the variable to be special,
so it makes other bindings also special.
That is the peril of relying on behavior that is not defined by the
standard. There are often multiple, reasonable choices that
implementations may make as far as how to react to non-conforming usage.
--
Thomas A. Russ, USC/Information Sciences Institute
In article <··············@gemini.franz.com>,
Duane Rettig <·····@franz.com> wrote:
> Rainer Joswig <······@lisp.de> writes:
>
> > In article <···············@mid.individual.net>,
> > Pascal Costanza <··@p-cos.net> wrote:
> >
> >> Rainer Joswig wrote:
>
> > In practice I can write at the top-level (setq bar 'foo)
> > and I have a global non-special variable.
>
> That's backwards; what you really have is a non-global special
> (in practice - most CLs do the special declaration).
I don't believe that. Are we talking about the same? ;-)
Welcome to OpenMCL Version 1.1-pre-070512 (DarwinX8664)!
? (setq bar 3)
3
Is bar now declared special??? I hope not! CMUCL did it.
But most CL implementations I know don't do that.
We are not talking about what is in the standard,
it is just about what is current practice.
? (defun foo (bar) (lambda () bar))
FOO
? (foo 3)
#<COMPILED-LEXICAL-CLOSURE #x300040D317BF>
It is still a closure. And bar is non-special.
> It's not global,
> not only in the sense that it wasn't declared with proclaim or
> declaim, but also because another binding of the same name does not
> take on the special-ness of 'bar assumed in the free reference. I
> don't know what other CLs call it, but in Allegro CL, we make the
> distinction between "special" and "globaly-special" for clarity of
> thinking.
>
> > Since any symbol has a value cell,
> > any form that introduces a symbol also introduces a value cell.
> > So any free variable bar could just point to the value
> > cell of the symbol bar, without any special declaration.
> >
> > Not sure if that is right, though...
>
> But remember that the compiler might take a lexical usage of this
> symbol (as a name) and compile it away:
>
> (defun foo (bar)
> (bas bar))
>
> This isn't a free variable, but it is the same one as had been used in
> a free reference. But when you then load the fasl file into another
> instance of the lisp, bar doesn't exist, but the compiled location
> (presumably on the stack) does exist, and (as in the original
> compiling lisp) the value of the variable is not a value cell, but
> something else.
Agreed.
If I do:
Welcome to OpenMCL Version 1.1-pre-070512 (DarwinX8664)!
? (defvar bar 3)
BAR
? (defun foo (bar) (lambda () bar))
FOO
? (foo 3)
#<Anonymous Function #x300040D3A81F>
So obviously there is a difference here. bar is special.
--
http://lispm.dyndns.org
Rainer Joswig <······@lisp.de> writes:
> In article <··············@gemini.franz.com>,
> Duane Rettig <·····@franz.com> wrote:
>
>> Rainer Joswig <······@lisp.de> writes:
>>
>> > In article <···············@mid.individual.net>,
>> > Pascal Costanza <··@p-cos.net> wrote:
>> >
>> >> Rainer Joswig wrote:
>>
>> > In practice I can write at the top-level (setq bar 'foo)
>> > and I have a global non-special variable.
>>
>> That's backwards; what you really have is a non-global special
>> (in practice - most CLs do the special declaration).
>
> I don't believe that. Are we talking about the same? ;-)
Yes. Before we proceed, though, I must say that my reference to most
CLs doing "the special declaration" was a little too broad; most CLs
only do (or assume) the special declaration during compilation.
But being special doesn't necessarily require an explicit special
declaration; it is defined in terms of usage. Note, for example, the
glossary term for "special variable": "n. Trad. A dynamic variable",
which if you follow the link it says "a variable the binding for which
is in the dynamic environment. See special." Note that
> Welcome to OpenMCL Version 1.1-pre-070512 (DarwinX8664)!
> ? (setq bar 3)
> 3
>
> Is bar now declared special??? I hope not!
Of course not; the context for the effective special declaration is
limited to the setq form. Does it make sense to make the declaration?
perhaps not. But, in fact, if you were to compile the form, or
perhaps a function which contains the form, a compiler may in fact do
just that (but only for the extent of the form being compiled).
> CMUCL did it.
I'm not an expert on CMUCL, but as far as I know what it did that was
different from other CLs was to proclaim/declaim it special (which
caused its "special"-ness to be global.
> But most CL implementations I know don't do that.
> We are not talking about what is in the standard,
> it is just about what is current practice.
>
> ? (defun foo (bar) (lambda () bar))
> FOO
>
> ? (foo 3)
> #<COMPILED-LEXICAL-CLOSURE #x300040D317BF>
>
> It is still a closure. And bar is non-special.
Again, we're talking about the difference between a global declaration
(a proclamation) and a non-global declaration.
In your same lisp, try the following similar thing as three forms (and
assuming you have not already proclaimed/declaimed bar to be special
in your lisp):
(let ((bar 10))
(declare (special bar))
(print bar))
(defun foo (bar) (lambda () (bar)))
(foo 3)
Is bar special in foo, even though it was declared special earlier?
Hopefully not, because bar was not declared _globally_ special.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
In article <··············@gemini.franz.com>,
Duane Rettig <·····@franz.com> wrote:
> Rainer Joswig <······@lisp.de> writes:
>
> > In article <··············@gemini.franz.com>,
> > Duane Rettig <·····@franz.com> wrote:
> >
> >> Rainer Joswig <······@lisp.de> writes:
> >>
> >> > In article <···············@mid.individual.net>,
> >> > Pascal Costanza <··@p-cos.net> wrote:
> >> >
> >> >> Rainer Joswig wrote:
> >>
> >> > In practice I can write at the top-level (setq bar 'foo)
> >> > and I have a global non-special variable.
> >>
> >> That's backwards; what you really have is a non-global special
> >> (in practice - most CLs do the special declaration).
> >
> > I don't believe that. Are we talking about the same? ;-)
>
> Yes. Before we proceed, though, I must say that my reference to most
> CLs doing "the special declaration" was a little too broad; most CLs
> only do (or assume) the special declaration during compilation.
>
> But being special doesn't necessarily require an explicit special
> declaration; it is defined in terms of usage. Note, for example, the
> glossary term for "special variable": "n. Trad. A dynamic variable",
> which if you follow the link it says "a variable the binding for which
> is in the dynamic environment. See special." Note that
>
> > Welcome to OpenMCL Version 1.1-pre-070512 (DarwinX8664)!
> > ? (setq bar 3)
> > 3
> >
> > Is bar now declared special??? I hope not!
>
> Of course not; the context for the effective special declaration is
> limited to the setq form. Does it make sense to make the declaration?
> perhaps not. But, in fact, if you were to compile the form, or
> perhaps a function which contains the form, a compiler may in fact do
> just that (but only for the extent of the form being compiled).
>
> > CMUCL did it.
>
> I'm not an expert on CMUCL, but as far as I know what it did that was
> different from other CLs was to proclaim/declaim it special (which
> caused its "special"-ness to be global.
>
> > But most CL implementations I know don't do that.
> > We are not talking about what is in the standard,
> > it is just about what is current practice.
> >
> > ? (defun foo (bar) (lambda () bar))
> > FOO
> >
> > ? (foo 3)
> > #<COMPILED-LEXICAL-CLOSURE #x300040D317BF>
> >
> > It is still a closure. And bar is non-special.
>
> Again, we're talking about the difference between a global declaration
> (a proclamation) and a non-global declaration.
>
> In your same lisp, try the following similar thing as three forms (and
> assuming you have not already proclaimed/declaimed bar to be special
> in your lisp):
>
> (let ((bar 10))
> (declare (special bar))
> (print bar))
>
> (defun foo (bar) (lambda () (bar)))
(defun foo (bar) (lambda () bar))
>
> (foo 3)
>
> Is bar special in foo, even though it was declared special earlier?
> Hopefully not, because bar was not declared _globally_ special.
Right.
--
http://lispm.dyndns.org
Rainer Joswig <······@lisp.de> writes:
> Btw. Duane, while you are here:
I'm always here :-)
> (defvar bar 3)
>
> (defun foo (bar) (lambda () bar))
>
> (foo 3)
>
> Allegro 8 says that the function returned is a closure.
> Any specific reasons for that?
Interesting that you should ask that now. We just had a support call
from a customer, and a lengthy discussion amongst ourselves, and we
decided to call this a bug. Not because a closure is created,
(because a closure with a null lexical environment is perfectly legal,
though sub-optimal), nor even that the environment is in fact non-null
(that is also a question of optimization, and we can't find any reason
why almost any special form, including defun, couldn't be implemented
with any number of lexical components in the environment, - a "foo
block", for example). But the bug is that we are including the
global-special in the environment that is copied for the closure,
rather than leaving it out, and the special happens to be the only
item in the lexical environment that makes the closure a non-null
lexical closure.
Note well, though, that we take this bug as a nominal one; it is one
of those times that if you go down two different paths in the spec,
you find two different answers: if you start with "special variable"
in the glossary, it leads you directly to "dynamic variable", which
then leads you to "dynamic environment" and the "special" declaration;
it implies that specials are dynamic and not lexical. On the other
hand, if you follow the path from "lexical environment", you see the
list of things included - it includes ordinary variable bindings
(which might be construed to leave out special bindings), but at the
end of the list it says "and local declarations (see declare)", both
of which takes you to the place which describes all declarations that
are not proclamations or declamations (and thus local) _including_ the
special declaration.
On the third hand, the description of let is explicit in that the
binding it establishes is lexical unless there is a special
declaration to the contrary (which implies that the special binding is
not in the lexical environment). On the fourth hand, there is CLtL2:
its definition of the interface for lexical environments clearly
includes specials, specially handled (i.e. not as part of the
declaration portion of the variable information, but as the first
return value for variable-information of :special (as opposed to
:lexical) - this implies that the special declaration _does_ get
included somehow into the lexical environment, but it is not lexical.
So in conclusion, we tend to believe that a special declaration has
both a lexical component and a dynamic component, and after much
consideration, we will continue to include the special in the working
environment, but we will also stop copying the special declaration
over when a lexical closure is made. This will not be done lightly,
and a lot of testing will go on before we release this. There are
various subtle ways other implementations seem to handle this, but
they tend to agree in not including the special into the lexical
closure, and we can see how it is not useful to do so on our part.
But I would be interested to know from other implementors what
philosophy they use; perhaps there is something we're missing...
Note finally that anyone can experiment with this: the function which
handles the copying of the environment for the purpose of making a
lexical closure is called sys::copy-environment, and the source is
available in the Environments Access module:
http://www.lispwire.com/entry-proganal-envaccess-des
The obvious fix is to exclude those items from being copied which
would result in a first-return-value of :special.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
On Tue, 05 Jun 2007 10:43:03 -0700, Duane Rettig <·····@franz.com> said:
| ...
| it is one
| of those times that if you go down two different paths in the spec,
| you find two different answers: if you start with "special variable"
| in the glossary, it leads you directly to "dynamic variable", which
| then leads you to "dynamic environment" and the "special" declaration;
| it implies that specials are dynamic and not lexical. On the other
| hand, if you follow the path from "lexical environment", you see the
| list of things included - it includes ordinary variable bindings
| (which might be construed to leave out special bindings), but at the
| end of the list it says "and local declarations (see declare)", both
| of which takes you to the place which describes all declarations that
| are not proclamations or declamations (and thus local) _including_ the
| special declaration.
But could the latter fragment of the glossary simply mean that it is
the declaration itself that is a part of the lexical environment,
i.e. would the structure of the text be as indicated by this
indentation:
A lexical environment contains, among other things:
ordinary bindings of variable names to values,
lexically established bindings of function names to functions,
macros,
symbol macros,
blocks,
tags,
and
local declarations (see declare).
(the first item corresponds (assuming we can establish a
correspondence between ANSI Common Lisp and CLtL2 Common Lisp, for
the sake of argument at least) to VARIABLE-INFORMATION, the second
and third one to FUNCTION-INFORMATION, and the seventh one to
DECLARATION-INFORMATION; the fourth, fifth, and sixth one do not
seem to have corresponding accessors)?
| On the third hand, the description of let is explicit in that the
| binding it establishes is lexical unless there is a special
| declaration to the contrary (which implies that the special binding is
| not in the lexical environment). On the fourth hand, there is CLtL2:
| its definition of the interface for lexical environments clearly
| includes specials, specially handled (i.e. not as part of the
| declaration portion of the variable information, but as the first
| return value for variable-information of :special (as opposed to
| :lexical) - this implies that the special declaration _does_ get
| included somehow into the lexical environment, but it is not lexical.
CLtL2, p. 208, says for VARIABLE-INFORMATION: "This function returns
information about the interpretation of the symbol _variable_ when
it appears as a variable within the lexical environment _env_."
Should we construe this as though it means, "within the scope of the
^^^^^^^^^^^^
lexical environment _env_"?
Or is :SPECIAL as the first value returned by VARIABLE-INFORMATION
specified in order to take care of a case such as (where X is not
declared in any way outside of this form):
(let ((x 0))
(let ((x 1))
(declare (special x))
... #| evaluate (variable-information 'x) with the environment here |#))
---what would VARIABLE-INFORMATION return there? Both NIL and
:LEXICAL would be wrong.
There are other questions in this context of varying level of
interest, for example, what should this evaluate to (again, absent
outside declarations of X):
(funcall (let ((x 0))
(let ((x 1))
(declare (special x))
#'(lambda () x))))
if it is not in error?
Finally, the last sentence in the description of
VARIABLE-INFORMATION says that "the global binding might differ from
the local one and can be retrieved by calling VARIABLE-INFORMATION
with a null lexical environment" (p. 209). So, what is returned if
we say
> (setq foo 'bar)
BAR
> (variable-information 'foo nil)
(I am trying to keep an open mind)?
---Vassil.
--
The truly good code is the obviously correct code.
Vassil Nikolov <···············@pobox.com> writes:
> On Tue, 05 Jun 2007 10:43:03 -0700, Duane Rettig <·····@franz.com> said:
> | ...
> | it is one
> | of those times that if you go down two different paths in the spec,
> | you find two different answers: if you start with "special variable"
> | in the glossary, it leads you directly to "dynamic variable", which
> | then leads you to "dynamic environment" and the "special" declaration;
> | it implies that specials are dynamic and not lexical. On the other
> | hand, if you follow the path from "lexical environment", you see the
> | list of things included - it includes ordinary variable bindings
> | (which might be construed to leave out special bindings), but at the
> | end of the list it says "and local declarations (see declare)", both
> | of which takes you to the place which describes all declarations that
> | are not proclamations or declamations (and thus local) _including_ the
> | special declaration.
>
> But could the latter fragment of the glossary simply mean that it is
> the declaration itself that is a part of the lexical environment,
> i.e. would the structure of the text be as indicated by this
> indentation:
>
> A lexical environment contains, among other things:
> ordinary bindings of variable names to values,
> lexically established bindings of function names to functions,
> macros,
> symbol macros,
> blocks,
> tags,
> and
> local declarations (see declare).
>
> (the first item corresponds (assuming we can establish a
> correspondence between ANSI Common Lisp and CLtL2 Common Lisp, for
> the sake of argument at least) to VARIABLE-INFORMATION, the second
> and third one to FUNCTION-INFORMATION, and the seventh one to
> DECLARATION-INFORMATION;
No. See 3.3.4: Declaration Scope, first paragraph: "Declarations can
be divided into two kinds: those that apply to the bindings of
variables or functions; and those that do not apply to bindings."
This is the trifold division between the three *-INFORMATION functions
as they were intended.
> the fourth, fifth, and sixth one do not
> seem to have corresponding accessors)?
Well, symbol-macros are part of the variable namespace, and it was
immediately obvious that CLtL2 had simply missed the functions
BLOCK-INFORMATION and TAG-INFORMATION (these are added to the
Environments Access module).
However, DECLARATION-INFORMATION is intended for the declarations that
do not apply to bindings, and _not_ to all local declarations (which,
if you look it up in the glossary, are simply any declarations made
using DECLARE, and which thus include declarations that apply to
bindings of variables and functions).
> | On the third hand, the description of let is explicit in that the
> | binding it establishes is lexical unless there is a special
> | declaration to the contrary (which implies that the special binding is
> | not in the lexical environment). On the fourth hand, there is CLtL2:
> | its definition of the interface for lexical environments clearly
> | includes specials, specially handled (i.e. not as part of the
> | declaration portion of the variable information, but as the first
> | return value for variable-information of :special (as opposed to
> | :lexical) - this implies that the special declaration _does_ get
> | included somehow into the lexical environment, but it is not lexical.
>
> CLtL2, p. 208, says for VARIABLE-INFORMATION: "This function returns
> information about the interpretation of the symbol _variable_ when
> it appears as a variable within the lexical environment _env_."
> Should we construe this as though it means, "within the scope of the
> ^^^^^^^^^^^^
> lexical environment _env_"?
Yes, of course; that is what "appears ... within" means.
> Or is :SPECIAL as the first value returned by VARIABLE-INFORMATION
> specified in order to take care of a case such as (where X is not
> declared in any way outside of this form):
>
> (let ((x 0))
> (let ((x 1))
> (declare (special x))
> ... #| evaluate (variable-information 'x) with the environment here |#))
>
> ---what would VARIABLE-INFORMATION return there? Both NIL and
> :LEXICAL would be wrong.
Of course; it returns :special as its first value.
> There are other questions in this context of varying level of
> interest, for example, what should this evaluate to (again, absent
> outside declarations of X):
>
> (funcall (let ((x 0))
> (let ((x 1))
> (declare (special x))
> #'(lambda () x))))
>
> if it is not in error?
This is what I was talking about as to a special having both lexical
and dynamic components. The innermost binding of x is not a lexical
binding, but it is lexically apparent that the reference to x is that
same special. On the other hand, by the time the funcall is
performed, after the return of the closure, the dynamic binding of x
has already disappeared, and we should get an unbound value error.
Note also that this is a case where the :special notation _must_ be in
the environment; the fact that it shadows the outer binding keeps the
funcall from (incorrectly) return 0. It is this lexical component
that does the shadowing, so in the closure that is generated for the
interpreted code, the special's lexical component must be included in
the copy.
> Finally, the last sentence in the description of
> VARIABLE-INFORMATION says that "the global binding might differ from
> the local one and can be retrieved by calling VARIABLE-INFORMATION
> with a null lexical environment" (p. 209). So, what is returned if
> we say
>
> > (setq foo 'bar)
> BAR
> > (variable-information 'foo nil)
It depends on what the scope of the implied special declaration is.
If the implementation decides to proclaim or declaim it a la CMUCL
style, then it will return values starting with :special. Otherwise,
it would return nil. Note however that there is no behavioral
difference between evaluating a 'foo that hasn't had any declarations,
and evaluating 'foo within a lexical closure that has as its current
binding for 'foo a :special binding; they both go to the symbol's
value cell for the answer. And if the value cell hasn't been bound
yet, then there should be an unbound variable error in both cases.
> (I am trying to keep an open mind)?
It seems so.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Rainer Joswig <······@lisp.de> writes:
> Welcome to OpenMCL Version 1.1-pre-070512 (DarwinX8664)!
> ? (setq bar 3)
> 3
>
> Is bar now declared special??? I hope not! CMUCL did it.
> But most CL implementations I know don't do that.
> We are not talking about what is in the standard,
> it is just about what is current practice.
Since at least one fairly major (CMUCL) implementation does proclaim
this special, it seems that current practice is split on what happens.
I would suspect, but can't test at the moment, that SBCL does something
similar.
--
Thomas A. Russ, USC/Information Sciences Institute
In article <···············@sevak.isi.edu>,
···@sevak.isi.edu (Thomas A. Russ) wrote:
> Rainer Joswig <······@lisp.de> writes:
> > Welcome to OpenMCL Version 1.1-pre-070512 (DarwinX8664)!
> > ? (setq bar 3)
> > 3
> >
> > Is bar now declared special??? I hope not! CMUCL did it.
> > But most CL implementations I know don't do that.
> > We are not talking about what is in the standard,
> > it is just about what is current practice.
>
> Since at least one fairly major (CMUCL)
For me CMUCL looks in a bit of a decline. Replaced by SBCL?
> implementation does proclaim
> this special, it seems that current practice is split on what happens.
> I would suspect, but can't test at the moment, that SBCL does something
> similar.
AFAICS SBCL doesn't do that.
--
http://lispm.dyndns.org
Rainer Joswig <······@lisp.de> wrote:
+---------------
| ···@sevak.isi.edu (Thomas A. Russ) wrote:
| > Since at least one fairly major (CMUCL)
|
| For me CMUCL looks in a bit of a decline. Replaced by SBCL?
+---------------
Hardly. Don't call CMUCL dead yet. There are a number of us
who still strongly prefer it to SBCL for various reasons, e.g.,
SBCL ripped out the interpreter & the byte-code compiler, both
of which *I* use to good effect with CMUCL in certain situations.
I think it's more accurate to say that the CMUCL developer & user
community is simply "quieter" than the SBCL folks. But "quiet"
doesn't mean "dead", just "stable" [like CL itself!].
-Rob
p.s. Speaking of which, though, whatever happened to that *other*
major CMUCL spinoff, Scieneer? <http://scieneer.com/> and
<http://scieneer.com/scl/index.html> seem to have been updated
recently, so I'm guessing they are still alive & kicking. They
seem to be supporting some interesting configurations at what
looks like reasonable prices: <http://scieneer.com/s/index.html>.
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Duane Rettig wrote:
> Rainer Joswig <······@lisp.de> writes:
>
>> In practice I can write at the top-level (setq bar 'foo)
>> and I have a global non-special variable.
>
> That's backwards; what you really have is a non-global special
> (in practice - most CLs do the special declaration).
Is there a way to determine whether or not a variable is special in
Allegro CL? EXCL::VARIABLE-SPECIAL-P seems likely. Or has that been
obsoleted by the addition of first class support for environments, i.e.
use VARIABLE-INFORMATION? (I've decided to ask this question here
because CLtL-2 environments as well as Allegro's implementation thereof,
IIRC, are not meant to be exclusive to Allegro.)
PG-USER> (defvar *duff* 69)
*DUFF*
PG-USER> (sys:variable-information '*duff*)
:SPECIAL
NIL
NIL
This is as I expected. *DUFF* is special. I've tried looking through
both the Allegro CL documentation for environments and the CLtL-2
section 8.5 but I can't seem to get an answer that I'm expecting for the
following DUFF variable.
PG-USER> (setq duff 13)
13
PG-USER> (sys:variable-information 'duff)
NIL
PG-USER>
From what you've written above, I would've expected that DUFF would
also be special, but that is not the answer I get from the above form.
I'm assuming, then, that this is because DUFF is not known in the global
environment but rather is special in a non-global environment. But I
can't seem to figure out how to get a handle on the environment in which
DUFF is known. For example:
PG-USER> (as sys:variable-information 'duff
(sys::make-augmentable-environment-boa :evaluation))
NIL
PG-USER>
How would one go about obtaining the environment in which DUFF is known?
On Tue, 05 Jun 2007 00:54:30 GMT, Damien Kick <·····@earthlink.net> said:
| ...
| I've tried looking through
| both the Allegro CL documentation for environments and the CLtL-2
| section 8.5 but I can't seem to get an answer that I'm expecting for
| the following DUFF variable.
| PG-USER> (setq duff 13)
| 13
| PG-USER> (sys:variable-information 'duff)
| NIL
| PG-USER>
| From what you've written above, I would've expected that DUFF would
| also be special, but that is not the answer I get from the above
| form. I'm assuming, then, that this is because DUFF is not known in
| the global environment but rather is special in a non-global
| environment. But I can't seem to figure out how to get a handle on
| the environment in which DUFF is known. For example:
| PG-USER> (as sys:variable-information 'duff
| (sys::make-augmentable-environment-boa :evaluation))
| NIL
| PG-USER>
| How would one go about obtaining the environment in which DUFF is known?
I'd say one wouldn't, because there is no such environment. (This
is based on "common sense", not on the specifics of Allegro CL's
implementation.)
---Vassil.
--
The truly good code is the obviously correct code.
Vassil Nikolov wrote:
> On Tue, 05 Jun 2007 00:54:30 GMT, Damien Kick <·····@earthlink.net> said:
>
> | PG-USER> (setq duff 13)
> | 13
> | PG-USER> (sys:variable-information 'duff)
> | NIL
> | PG-USER> (as sys:variable-information 'duff
> | (sys::make-augmentable-environment-boa :evaluation))
> | NIL
> | PG-USER>
>
> | How would one go about obtaining the environment in which DUFF is known?
>
> I'd say one wouldn't, because there is no such environment. (This
> is based on "common sense", not on the specifics of Allegro CL's
> implementation.)
PG-USER> (setq duff 13)
13
PG-USER> duff
13
PG-USER>
Obviously there is some environment in which DUFF is known to have a
binding.
On Tue, 05 Jun 2007 01:53:44 GMT, Damien Kick <·····@earthlink.net> said:
| ...
| PG-USER> (setq duff 13)
| 13
| PG-USER> duff
| 13
| PG-USER>
| Obviously there is some environment in which DUFF is known to have a
| binding.
Maybe this is open to interpretation---maybe we are counting how
many conses will fit on the tip of a cdr---but in my suitably humble
opinion, the above does not demonstrate the existence of an
environment, but only that the implementation falls back to calling
(SETF SYMBOL-VALUE) and then SYMBOL-VALUE, in exasperation, as it
were (or perhaps because its first duty is to evaluate and
serve...).
(If you say the above is counter-intuitive, I'd agree, especially
with regards to a global-lexical-environment-based intuition.)
---Vassil.
--
The truly good code is the obviously correct code.
Vassil Nikolov wrote:
> On Tue, 05 Jun 2007 01:53:44 GMT, Damien Kick <·····@earthlink.net> said:
> | ...
> | PG-USER> (setq duff 13)
> | 13
> | PG-USER> duff
> | 13
> | PG-USER>
>
> | Obviously there is some environment in which DUFF is known to have a
> | binding.
>
> Maybe this is open to interpretation---maybe we are counting how
> many conses will fit on the tip of a cdr---but in my suitably humble
> opinion, the above does not demonstrate the existence of an
> environment, [...]
I think that the standard makes it pretty clear what an environment
<http://www.lisp.org/HyperSpec/Body/sec_3-1-1.html> is:
<blockquote>
A binding is an association between a name and that which the name
denotes. Bindings are established in a lexical environment or a dynamic
environment by particular special operators.
An environment is a set of bindings and other information used during
evaluation (e.g., to associate meanings with names).
</blockquote>
Clearly there is a binding for DUFF. I just don't know how obtain the
object representing the environment so that I can use it to obtain
variable-information about the name DUFF.
Damien Kick <·····@earthlink.net> writes:
> Duane Rettig wrote:
>> Rainer Joswig <······@lisp.de> writes:
>>
>>> In practice I can write at the top-level (setq bar 'foo)
>>> and I have a global non-special variable.
>> That's backwards; what you really have is a non-global special
>> (in practice - most CLs do the special declaration).
>
> Is there a way to determine whether or not a variable is special in
> Allegro CL?
Well, you're talking about symbols, and all symbols have value cells,
so all symbols can be special (i.e. when you perform an operation that
works on the global value of the symbol, such as symbol-value, or
boundp, the symbol is automatically treated as special; if such a form
is compiled, the compiler cannot compile away the reference to the
symbol (or at least a way to get to that specific symbol's value cell).
> EXCL::VARIABLE-SPECIAL-P seems likely. Or has that been
> obsoleted by the addition of first class support for environments,
> i.e. use VARIABLE-INFORMATION?
Interestingly, this function, which has roots in the PCL clos walker,
is now defined in Allegro CL as:
(defun variable-special-p (var env)
(eq :special (sys:variable-information var env t)))
> (I've decided to ask this question
> here because CLtL-2 environments as well as Allegro's implementation
> thereof, IIRC, are not meant to be exclusive to Allegro.)
Correct. I assume that if any other implementations provide the
Environments Access module to the deepest level implementation (where
the module actually provides all of the information for the compiler
and possibly the interpreter, rather than emulating the information in
the implementation's native environment representation) that by that
time any such checks for speciallness would eventually find their way
to calling variable-information.
> PG-USER> (defvar *duff* 69)
> *DUFF*
> PG-USER> (sys:variable-information '*duff*)
> :SPECIAL
> NIL
> NIL
>
> This is as I expected. *DUFF* is special.
Correct. This is because defvar has proclaimed/devclaimed *duff* to
be special globally, and that will last outside of the defvar form.
I've tried looking through
> both the Allegro CL documentation for environments and the CLtL-2
> section 8.5 but I can't seem to get an answer that I'm expecting for
> the following DUFF variable.
>
> PG-USER> (setq duff 13)
> 13
> PG-USER> (sys:variable-information 'duff)
> NIL
> PG-USER>
> From what you've written above, I would've expected that DUFF would
> also be special, but that is not the answer I get from the above
> form. I'm assuming, then, that this is because DUFF is not known in
> the global environment but rather is special in a non-global
> environment.
That's because you're not looking at the point where duff is assumed
to be special, which is only within the setq form. It is really its
usage that treats *duff* as special. Now, it seems ludicrous to try
to pick apart a setq form, so I wouldn't expect an interpreter to
bother to make the actual declaration, followed by the execution of
the setq special-form, which is a one-shot deal. It _could_ be done,
but how would you get your hands on the environment? It's just not
practical to be able to catch the declaration in the act. However ...
(read on ...)
But I can't seem to figure out how to get a handle on
> the environment in which DUFF is known. For example:
>
> PG-USER> (as sys:variable-information 'duff
> (sys::make-augmentable-environment-boa :evaluation))
> NIL
> PG-USER>
>
> How would one go about obtaining the environment in which DUFF is known?
Well, here's a cute compiler trick, based on the fact that Allegro CL
adds any automatic declarations of a special within an actual
environment "contour" (a lambda or a let, which tend to be the places
where things get bound and declared). Starting with a little macro
magic, you can get the information you ask for after the setq, though
you do also get a lot of extra internal compiler cruft as well:
CL-USER(1): (defmacro with-vi-test ((var &optional all) &body body &environment e)
(format t "variable-information ~:[~;(all)~] of ~s is ~s~%"
all var (multiple-value-list (sys:variable-information var e all)))
`(progn ,@body))
WITH-VI-TEST
CL-USER(2): (defun foo ()
(setq bar 'hi)
(with-vi-test (bar) 'bye))
FOO
CL-USER(3): (compile *)
; While compiling FOO:
Warning: Free reference to undeclared variable BAR assumed special.
variable-information of BAR is (:SPECIAL
... )
FOO
T
T
CL-USER(4):
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
In article <··············@tan-ru.localdomain>,
Richard M Kreuter <·······@progn.net> wrote:
> Rainer Joswig <······@lisp.de> writes:
>
> > I've never understood why there are no non-special
> > global variables in ANSI Common Lisp. Introducing a global
> > variable in Common Lisp automatically means that
> > ALL local variables of that name are special, too.
>
> There was a proposal for lexical declarations that would have included
> global lexical variables [1]. AFAICT, there were many subtleties
> invloved and not enough established practice.
>
> [1] http://www.nhplace.com/kent/CL/Issues/proclaim-lexical.html
Thanks for the pointer. This is exactly one of the
things 'I' would like to see 'standardized' - whatever
that means. ;-)
--
http://lispm.dyndns.org
(message (Hello 'Don)
(you :wrote :on '(Sat, 02 Jun 2007 12:18:04 -0700))
(
DG> The implementations are being nice to you, by giving you what you mean,
DG> even if you didn't express it as required. SBCL has chosen to warn you
DG> that you aren't writing strict ANSI CL.
i first thought that i don't really need to be 100% ANSI CL in REPL
experimentations -- if implementation eats it, it should be ok..
but later i've found that in implementation i'm using -- ABCL -- variables
introduced via SETQ behave different from normal special varibles, i
remember there were some glitches in threading -- those variables are not
visible to all threads, or something like that..
so now i use DEFPARAMETER even in REPL :)
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"I am everything you want and I am everything you need")
On Sat, 02 Jun 2007 20:14:05 +0200, anders <················@gmail.com>
wrote:
> I have 3 enviroment to run LISP
>
> Linux and CLISP
> Windows and CLISP
> OS/X and SBCL
>
> On SBCL
> a get a warning that a variabel is not defined when a do a
> (setq x 10)
> it is a WARNING and it sets x = 10
>
> If i do the same on CLISP i get no warning
>
> Anyone can tell me way and sould i not use SETQ to enter new
> variabels / Konstant
> my LISP book says this is the way soo.
>
> // Anders
>
In general defvar or defparameter is better.
It is in general bad form to set variables before declaring them.
Defvar will set the variable only once when it is loaded.
Defparameter will set the variable each time the form is reevaluated
(compiled).
Also it is better to use setf rather than setq. It is more general and thus
lead to a a more consistent style of assignment.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
(message (Hello 'anders)
(you :wrote :on '(Sat, 02 Jun 2007 11:14:05 -0700))
(
a> Anyone can tell me way and sould i not use SETQ to enter new
a> variabels / Konstant
a> my LISP book says this is the way soo.
you should use SETQ/SETF only with existing variables. if variable is not
declared, behaviour is implementation-specific.
you should use DEFPARAMETER to create a new variable, or to change it's
value if you are not sure.
you should use DEFVAR in a source file if you want to avoid overwriting
current variable value when loading that source file.
you should use DEFCONSTANT for values that does not change.
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"I am everything you want and I am everything you need")