Hi,
I am looking at this code written by someone else.
I see variable name with *, eg *lines-from-transform*,
is there special reason for using *'s here?
Thanks.
- Jay
Hyunchul Jay Kim <········@andrew.cmu.edu> writes:
> Hi,
> I am looking at this code written by someone else.
> I see variable name with *, eg *lines-from-transform*,
>
> is there special reason for using *'s here?
>
>
> Thanks.
> - Jay
Convention. All global variables are surrounded with *'s. Sometimes
constants are surrounded with +'s rather than *'s.
Sunil
In article <········································@russell2.phil.cmu.edu>,
Hyunchul Jay Kim <········@andrew.cmu.edu> writes:
> I am looking at this code written by someone else. I see variable name
> with *, eg *lines-from-transform*, is there special reason for using *'s
> here?
This is a stylistic convention for indicating that a given variable is
special (that is, dynamically rather than lexically scoped). Compare
standard Common Lisp variables such as *PACKAGE*.
--
Aaron Crane <···········@pobox.com> <URL:http://pobox.com/~aaronc/>
** Please send on-topic followups by Usenet, not email **
Hyunchul Jay Kim <········@andrew.cmu.edu> writes:
>
> Hi,
> I am looking at this code written by someone else.
> I see variable name with *, eg *lines-from-transform*,
>
> is there special reason for using *'s here?
Funny you should word it that way.
There is a kind of variable called a "special variable" which is
dynamically rather than lexically bound. The convention that is
almost universally observed (though not required) is to put *'s
on the ends of special variable names so they are easy to spot since
they work very differently than other variables.
Check your manual for info on special or dynamic variables.
>Hyunchul Jay Kim <········@andrew.cmu.edu> writes:
>>
>> I am looking at this code written by someone else.
>> I see variable name with *, eg *lines-from-transform*,
>>
>> is there special reason for using *'s here?
I've read the other responses and I think the following
"defensive programming" point needs some airing.
In Common Lisp, you don't ever want to introduce a
nonglobal lexical variable with an identifier that is
also used for a global variable. The * convention is
an attempt to ensure that the identifiers used for
global and nonglobal variables will always be
different.
--d
In article <············@news.gte.com>,
Dorai Sitaram <····@bunny.gte.com> wrote:
...
>"defensive programming" point needs some airing.
...
>In Common Lisp, you don't ever want to introduce a
>nonglobal lexical variable with an identifier that is
>also used for a global variable.
"ever" is perhaps too strong. :-)
Contexts akin to the following may be useful.
(let ( ( *special-global* ...some expression.... )
... )
...
)
or
(defun foo ( *special-global* )
... )
"Temporarlily" reset this dynamic global variable to some other value and
automagically reset to the prevous value when exit the local context.
However, you (or, perhaps more problematic, anyone else's code that shares
the same lisp environment ) don't ever want to unintentionally introduce a
....
--
Lyman S. Taylor "Computers are too reliable to replace
(·····@cc.gatech.edu) humans effectively."
Commander Nathan Spring, "Starcops"
In article <··········@pravda.cc.gatech.edu>,
Lyman S. Taylor <·····@cc.gatech.edu> wrote:
>In article <············@news.gte.com>,
>Dorai Sitaram <····@bunny.gte.com> wrote:
>...
>>"defensive programming" point needs some airing.
>...
>>In Common Lisp, you don't ever want to introduce a
>>nonglobal lexical variable with an identifier that is
>>also used for a global variable.
>
> "ever" is perhaps too strong. :-)
"ever" is exactly right. :-) The following examples do
not introduce a nonglobal lexical variable. Indeed, it
is because of the following kinds of uses that I said
what I said.
--d
> Contexts akin to the following may be useful.
>
> (let ( ( *special-global* ...some expression.... ) ...
>
> or
>
> (defun foo ( *special-global* ) ...
·····@cc.gatech.edu (Lyman S. Taylor) writes:
> In article <············@news.gte.com>,
> Dorai Sitaram <····@bunny.gte.com> wrote:
> ...
> >"defensive programming" point needs some airing.
> ...
> >In Common Lisp, you don't ever want to introduce a
> >nonglobal lexical variable with an identifier that is
> >also used for a global variable.
>
> "ever" is perhaps too strong. :-)
>
> Contexts akin to the following may be useful.
> (let ( ( *special-global* ...some expression.... ) ...) ...)
> or
> (defun foo ( *special-global* ) ... )
I had assumed he meant the following is bad:
(defvar foo 1)
(defun bar (foo) #'(lambda () foo))
Here FOO is apparently introduced for lexical value but because it
is the name of a special, the closure over foo fails.
I ran into a zillion of these when translating Macsyma from Maclisp
to Common Lisp years ago. The Maclisp experience was surely the
genesis of the desire to create a naming convention distinguishing
specials from lexicals. Probably the only reason we didn't require
it was that there was a lot of old code to compatibly support.
In article <···············@world.std.com>,
Kent M Pitman <······@world.std.com> writes:
> (defvar foo 1)
> (defun bar (foo) #'(lambda () foo))
>
> Here FOO is apparently introduced for lexical value but because it
> is the name of a special, the closure over foo fails.
>
> I ran into a zillion of these when translating Macsyma from Maclisp
> to Common Lisp years ago. The Maclisp experience was surely the
> genesis of the desire to create a naming convention distinguishing
> specials from lexicals. Probably the only reason we didn't require
> it was that there was a lot of old code to compatibly support.
This is one of the things I really like about the ISLisp specification. In
ISLisp, once a variable has been declared special (with DEFDYNAMIC) it must
be accessed with the special form DYNAMIC; its value may be changed with
DYNAMIC-LET:
(defdynamic foo 1)
(defun bar () (dynamic foo))
(dynamic-let ((foo 2))
(bar)) ==> 2
While *FOO* is a reasonable convention for visually marking special
variables, using additional syntax in the shape of DYNAMIC and friends is
certainly less error-prone. The other side of the argument is that the
additional benefit (when compared to a strict adherence to the *-*
convention) may not be worth the increased cost in terms of verbosity.
--
Aaron Crane <···········@pobox.com> <URL:http://pobox.com/~aaronc/>
** Please send on-topic followups by Usenet, not email **
In article <···············@edlhp208.ed.ray.com>,
Johan Kullstam <········@ne.mediaone.net> writes:
> accessing a dynamic-variable via (dynamic x) seems just as good as the
> (funcall x) needed to access a function.
I don't think FUNCALL is the equivalent of DYNAMIC, as it takes a function
object, rather than a name. Just as ISLisp DYNAMIC takes an implicitly
quoted symbol and returns its dynamic value, FUNCTION (in both ISLisp and
Common Lisp) takes an implicitly quoted symbol and returns its function
value (or more exactly, the value of its function cell). (SYMBOL-FUNCTION
differs in that its symbol argument is not quoted.)
> rather than dynamic-let, i think dynamic should be setf-able. as in (setf
> (dynamic g) 3).
It *is* SETF-able. Apologies for giving a misleading impression in my
earlier article. (And of course, given the meta-circular nature of Lisp, we
could easily write DYNAMIC-LET in terms of (SETF (DYNAMIC)) and
UNWIND-PROTECT.)
--
Aaron Crane <···········@pobox.com> <URL:http://pobox.com/~aaronc/>
** Please send on-topic followups by Usenet, not email **
···········@pobox.com (Aaron Crane) writes:
> In article <···············@edlhp208.ed.ray.com>,
> Johan Kullstam <········@ne.mediaone.net> writes:
> > accessing a dynamic-variable via (dynamic x) seems just as good as the
> > (funcall x) needed to access a function.
>
> I don't think FUNCALL is the equivalent of DYNAMIC, as it takes a function
> object, rather than a name. Just as ISLisp DYNAMIC takes an implicitly
> quoted symbol and returns its dynamic value, FUNCTION (in both ISLisp and
> Common Lisp) takes an implicitly quoted symbol and returns its function
> value (or more exactly, the value of its function cell). (SYMBOL-FUNCTION
> differs in that its symbol argument is not quoted.)
you are right, of course. i spoke too quickly.
btw what would be the effect of moving dynamics to their own slot in
the symbol work with lisp? are there ever cases where you want to
introduce a special variable without stars in its name in order to
usurp some local variables? or can i assume that dynamic variables
and lexical variable should always have their own namespace (whether
by the * * and lack of star for dyn and lex resp convention or some
language structure enforcement via the DYNAMIC construct)?
--
johan kullstam
Johan Kullstam <········@ne.mediaone.net> writes:
> btw what would be the effect of moving dynamics to their own slot in
> the symbol work with lisp? are there ever cases where you want to
> introduce a special variable without stars in its name in order to
> usurp some local variables?
yes. I use specials without stars much more frequently than you'd expect.
It's very useful to "pun" on the idea that there are values associated
with ordinary symbol names when writing toy interpreters or bootstrapping
special purpose embedded languages or doing various things where
you let the user specify a form to eval but you don't want to pass him
lots of args.
(let ((frob frob1))
(declare (special frob))
(eval something))
there are sevearl reasons for not just requiring the something to have *frob*.
first, it might be translated from something where the name frob has other
uses and relies on the pun of having both a value and a function.
second, some think the *frob* stuff is ugly and tedious and want
to once in a while climb out of it. it serves a purpose, but at an
esthetic cost. third, allowing the capability of both doesn't cost
anything other than human readability, and even then only when you
drift from the established guidelines. you can write a program to
automatically check your code if you want a more restrictive lifestyle;
imposing that lifestyle on others is unreasonable. compatibility
packages for maclisp, scheme, emacs-lisp, and others use this feature.
i could go on.
> or can i assume that dynamic variables
> and lexical variable should always have their own namespace (whether
> by the * * and lack of star for dyn and lex resp convention or some
> language structure enforcement via the DYNAMIC construct)?
it's good style to always put the *'s unless you have a reason
not to. if you want to defmacro a dynamic and dynamic-let
construct, you can. it's a design error in cl, imo, that dynamic-let
is not used instead of a declaration, to identify special bindings.
splitting declarations into those that can be ignored and those
that cannot is tedious. having a different way to deal with those
that cannot be ignored would have been syntactically wise.
but that's an orthogonal point to the naming issue.
sorry if this message seems a bit short. it's not to do with this
topic. i'm just in a bad mood for other reason. but i wanted to reply
anyway because i had informationt o share. hope it helps.
Kent M Pitman <······@world.std.com> writes:
> sorry if this message seems a bit short. it's not to do with this
> topic. i'm just in a bad mood for other reason. but i wanted to reply
> anyway because i had informationt o share. hope it helps.
thanks for your answer. i see that there may be a purpose to having
non-starred dynamic variables. i shall still keep to the convention
until i know better what i am trying to do.
--
J o h a n K u l l s t a m
[········@ne.mediaone.net]
Don't Fear the Penguin!
In article <·············@res.raytheon.com>,
Johan Kullstam <········@ne.mediaone.net> wrote:
>btw what would be the effect of moving dynamics to their own slot in
>the symbol work with lisp?
MDL had something like this. There were two different syntaxes for
accessing a variable, one to access its lexical value and another to access
its dynamic value (something like ".var" and ",var", I think).
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
In article <·············@res.raytheon.com>,
Johan Kullstam <········@ne.mediaone.net> wrote:
(...)
> btw what would be the effect of moving dynamics to their own slot in
> the symbol work with lisp? are there ever cases where you want to
> introduce a special variable without stars in its name in order to
> usurp some local variables? or can i assume that dynamic variables
> and lexical variable should always have their own namespace (whether
> by the * * and lack of star for dyn and lex resp convention or some
> language structure enforcement via the DYNAMIC construct)?
Let me offer you this point of view. There are three kinds of special
variables:
(1) Global special variables---introduced by DEFVAR. One would have
very serious reasons not to use asterisks around the name, and
this would be very very rare, I think.
(2) Local special variables---introduced by localised special
declarations just where they are used. I think such use is rarely
justified, but when it is, I'd say it is 50-50 if there would be
asterisks.
(3) Implicit special variables---undeclared, and simply used as free
variables (i.e. not appearing in a lambda list or the variable
list of a LET or LET-like form; one often gets compiler warnings
about these). I'd say it is the usual case that their names have
no asterisks.
The above is of course a `syntactic' classification; for `pragmatic'
considerations see Kent Pitman's posting.
Good luck, and be kind to your special variables,
Vassil.
Vassil Nikolov <········@poboxes.com> www.poboxes.com/vnikolov
(You may want to cc your posting to me if I _have_ to see it.)
LEGEMANVALEMFVTVTVM (Ancient Roman programmers' adage.)
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
* Vassil Nikolov <········@poboxes.com>
| Let me offer you this point of view. There are three kinds of special
| variables:
|
| (1) Global special variables...
| (2) Local special variables...
| (3) Implicit special variables...
PROGV doesn't seem to fit either of these categories. should it?
#:Erik
In article <················@naggum.no>,
Erik Naggum <····@naggum.no> wrote:
> * Vassil Nikolov <········@poboxes.com>
> | Let me offer you this point of view. There are three kinds of special
> | variables:
> |
> | (1) Global special variables...
> | (2) Local special variables...
> | (3) Implicit special variables...
>
> PROGV doesn't seem to fit either of these categories. should it?
No, indeed it does not and it should not.
You are right in pointing out that I was not quite precise. I should
have written something like, `three kinds of special variables that
exist/are specified at program-writing time (compile time).' (This is
probably not the best formulation.)
Then there is, of course, as you write, the issue of variables being
created at run time. I mean those created with INTERN, GENSYM, etc.,
whose values are got/set with SYMBOL-VALUE and SETF thereof, and which
are bound with PROGV.
Now things start getting complicated here. If the list of variable
names given to PROGV is a constant, are the variables not actually
specified at program-writing time? Or, consider a macro expansion
function that calls GENSYM to produce local variables: what is
run time for the macro expansion function is compile time for the
function containing the macro call. Or, there may be mixes (whether
desired or not), e.g. when one obtains a string at run time, interns
it, and passes it to SYMBOL-VALUE or PROGV, and the symbol thus
produced happens to be one that appears in a special declaration.
I don't have any ready answers here; it's not that I have no thoughts
on this matter, but if I have to formulate them, I shall need to take
time thinking them over. In my previous posting, I offered just
a simplification which I believed had some practical value in spite of
not being comprehensive.
I also see now that I am less certain about a terminological issue than
I would like to be. I must have identified special and dynamic variables
(well, in fact so does the CLHS glossary, but that is not an excuse...).
I am not saying that there should be a semantic distinction, but from a
pragmatic point of view `special' could be taken to imply that the
variable is declared or at least `declarable'---i.e. that it exists at
compile time. On the other hand, I cannot declare anything about
variables created at run time (well, again we come to the issue that
one program's run time may be another program's compile time).
Well, if one accepts this distinction between `special' and `dynamic'
(I know this might be a big `if'), then PROGV is not about special
variables in this sense of `special,' and the statement in my previous
posting should be taken in this sense. But this would have excused me
if I had thought about this issue in advance.
I shall be happy to read comments on these matters.
Vassil Nikolov <········@poboxes.com> www.poboxes.com/vnikolov
(You may want to cc your posting to me if I _have_ to see it.)
LEGEMANVALEMFVTVTVM (Ancient Roman programmers' adage.)
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
In article <··············@planet.praeclarus.demon.co.uk>,
···········@pobox.com (Aaron Crane) wrote:
> In article <···············@edlhp208.ed.ray.com>,
> Johan Kullstam <········@ne.mediaone.net> writes:
(...)
> And of course, given the meta-circular nature of Lisp,
> we could easily write DYNAMIC-LET in terms of (SETF (DYNAMIC)) and
> UNWIND-PROTECT.
(1) Wouldn't this explicitly restrict us to shallow binding?
(2) Would this be the same as writing a DYNAMIC-LET for Common
Lisp in terms of SETF of SYMBOL-FUNCTION and UNWIND-PROTECT?
(Again shallow binding only.) I don't know ISLisp and the
exact definition of DYNAMIC and DYNAMIC-LET, hence the question.
Have a nice day or night,
Vassil.
Vassil Nikolov <········@poboxes.com> www.poboxes.com/vnikolov
(You may want to cc your posting to me if I _have_ to see it.)
LEGEMANVALEMFVTVTVM (Ancient Roman programmers' adage.)
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
In article <············@nnrp1.dejanews.com>,
Vassil Nikolov <········@poboxes.com> writes:
> In article <··············@planet.praeclarus.demon.co.uk>,
> ···········@pobox.com (Aaron Crane) wrote:
> > And of course, given the meta-circular nature of Lisp, we could easily
> > write DYNAMIC-LET in terms of (SETF (DYNAMIC)) and UNWIND-PROTECT.
>
> (1) Wouldn't this explicitly restrict us to shallow binding?
I don't follow this question. My understanding was that shallow binding ==
lexical scoping, and deep binding == dynamic scoping (or special variables
as CL puts it). What additional distinction are you drawing?
> (2) Would this be the same as writing a DYNAMIC-LET for Common Lisp in
> terms of SETF of SYMBOL-FUNCTION and UNWIND-PROTECT? (Again shallow
> binding only.)
Yes, I think so (modulo the shallow-binding thing, and assuming that you
meant SYMBOL-VALUE rather than SYMBOL-FUNCTION).
> I don't know ISLisp and the exact definition of DYNAMIC and
> DYNAMIC-LET, hence the question.
To be quite frank, nor do I. I read the specification, and thought it had
some interesting aspects; this DYNAMIC thing was one of them. It seems to
be an area where ISLisp is a simpler dialect than Common Lisp. For example,
as far as I can tell the value-punning that Kent Pitman talked about in
article <···············@world.std.com> isn't possible.
--
Aaron Crane <···········@pobox.com> <URL:http://pobox.com/~aaronc/>
** Please send on-topic followups by Usenet, not email **
In article <··············@planet.praeclarus.demon.co.uk>,
Aaron Crane <···········@pobox.com> wrote:
>I don't follow this question. My understanding was that shallow binding ==
>lexical scoping, and deep binding == dynamic scoping (or special variables
>as CL puts it). What additional distinction are you drawing?
No, shallow and deep binding are two ways of implementing dynamic
bindings. With shallow bindings you save the old value on a stack and
store into the value cell of the object. With deep bindings the dynamic
environment is an association list of objects and their bindings, and you
make a new binding by pushing an entry onto the front of the list.
Are deep bindings every really used in serious implementations? I've
rarely encountered it, and I tend to think of them more as an issue for
academic discussion of design techniques. The benefit of deep binding is
that stack unwinding is cheap, but at the expense of slow dynamic variable
access, and this seems like a poor tradeoff.
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Barry Margolin wrote:
>
> In article <··············@planet.praeclarus.demon.co.uk>,
> Aaron Crane <···········@pobox.com> wrote:
> >I don't follow this question. My understanding was that shallow binding ==
> >lexical scoping, and deep binding == dynamic scoping (or special variables
> >as CL puts it). What additional distinction are you drawing?
>
> No, shallow and deep binding are two ways of implementing dynamic
> bindings. With shallow bindings you save the old value on a stack and
> store into the value cell of the object. With deep bindings the dynamic
> environment is an association list of objects and their bindings, and you
> make a new binding by pushing an entry onto the front of the list.
>
> Are deep bindings every really used in serious implementations? I've
> rarely encountered it, and I tend to think of them more as an issue for
> academic discussion of design techniques. The benefit of deep binding is
> that stack unwinding is cheap, but at the expense of slow dynamic variable
> access, and this seems like a poor tradeoff.
Shallow binding is great if you don't have multiple threads
that want their own private bindings of dynamic variables.
For a time-shared, serial implementation, this can still work
but you pay for it when you switch threads since you must
save the current binding from the global value cell, and
rewrite the new binding from the new stack.
With deep binding, a context-switch is very fast and simple,
and moreover, doesn't write value cells all over memory.
The downside is the slower lookups algorithm, but in fact,
if you structure the binding stack well it can be in cache,
and moreover, recently bound variables will be "on top".
So for example, in my OODB, the variable is *current-database*
is looked-up often, but it will be found quickly.
The real loser in this deal is truly global variables,
since you must always waste time scanning the binding stack,
instead of just going directly to the value cell.
In my true-multiprocessor TopCL implementation,
I added (defglobal var val) that told the compiler to
generate straight value-cell lookups to avoid the problem.
But CL variables like *print-pretty* and friends, which
are not often bound but in some cases looked-up often,
e.g. #'format e.g. it can slow things down.
This is why special variables are to be avoided,
and even eliminated if possible...unless
you really need a dynamically bound variable.
-Kelly Murray ···@niclos.com
From: Vassil Nikolov
Subject: `fast' global variables (Ex: Re: ??: using * for variable ?)
Date:
Message-ID: <7d4165$acl$1@nnrp1.dejanews.com>
In article <·················@IntelliMarket.Com>,
Kelly Murray <···@IntelliMarket.Com> wrote:
(...)
> The real loser in this deal is truly global variables,
> since you must always waste time scanning the binding stack,
> instead of just going directly to the value cell.
> In my true-multiprocessor TopCL implementation,
> I added (defglobal var val) that told the compiler to
> generate straight value-cell lookups to avoid the problem.
>
> But CL variables like *print-pretty* and friends, which
> are not often bound but in some cases looked-up often,
> e.g. #'format e.g. it can slow things down.
>
> This is why special variables are to be avoided,
> and even eliminated if possible...unless
> you really need a dynamically bound variable.
Indeed.
If I need a `bindable' global variable, I just have to grin
and bear it.
If I need an unbindable and unchangeable global variable, this
is in fact no variable but a constant, and I have DEFCONSTANT,
with O(1) access time (not to mention possibilities for
optimisation).
Now, the point---what if I need an unbindable but changeable
global variable in Common Lisp (i.e. I don't have DEFGLOBAL)
which is accessible (both for reading and writing) in O(1)?
I can't do (DEFCONSTANT FOO (MAKE-ARRAY NIL)) and then
(AREF FOO) for getting the value and (SETF (AREF FOO) value) ;ERROR!
for setting the value, though perhaps it would have been nice if
I could. Using the function value of a symbol (which is changeable
but unbindable) directly is not allowed for arbitrary objects so
the best way I know is to use a closure: use
(let ((foo init))
(defun get-foo () foo)
(defun set-foo (value) (setf foo value)))
and make things look like a real variable by using DEFINE-SYMBOL-MACRO,
defining SETF of GET-FOO, and declaiming GET-FOO and SET-FOO inline.
Is there any better way?
Vassil Nikolov <········@poboxes.com> www.poboxes.com/vnikolov
(You may want to cc your posting to me if I _have_ to see it.)
LEGEMANVALEMFVTVTVM (Ancient Roman programmers' adage.)
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
From: Tim Bradshaw
Subject: Re: `fast' global variables (Ex: Re: ??: using * for variable ?)
Date:
Message-ID: <nkj7lsa5luz.fsf@tfeb.org>
Vassil Nikolov <········@poboxes.com> writes:
> I can't do (DEFCONSTANT FOO (MAKE-ARRAY NIL)) and then
> (AREF FOO) for getting the value and (SETF (AREF FOO) value) ;ERROR!
> for setting the value, though perhaps it would have been nice if
> I could.
But allocating a single-element array will work just fine, or, perhaps
better, a structure with one slot. Then you just need suitable GLOBAL
and (SETF GLOBAL) syntax, and you're home and dry.
--tim
From: Vassil Nikolov
Subject: Re: `fast' global variables (Ex: Re: ??: using * for variable ?)
Date:
Message-ID: <7d6d6d$b63$1@nnrp1.dejanews.com>
In article <···············@tfeb.org>,
Tim Bradshaw <···@tfeb.org> wrote:
> Vassil Nikolov <········@poboxes.com> writes:
>
> > I can't do (DEFCONSTANT FOO (MAKE-ARRAY NIL)) and then
> > (AREF FOO) for getting the value and (SETF (AREF FOO) value) ;ERROR!
> > for setting the value, though perhaps it would have been nice if
> > I could.
>
> But allocating a single-element array will work just fine, or, perhaps
> better, a structure with one slot. Then you just need suitable GLOBAL
> and (SETF GLOBAL) syntax, and you're home and dry.
Sorry, I don't get your point. A zero-dimensional array is my
favourite single-slot structure; but I need to refer to it somehow---
if not by a global variable or a global function (which is a lexical
closure), how else? (I mean, without amending Common Lisp to have
global lexicals (I believe this is the name for what I have wanted in
this thread).)
Vassil Nikolov <········@poboxes.com> www.poboxes.com/vnikolov
(You may want to cc your posting to me if I _have_ to see it.)
LEGEMANVALEMFVTVTVM (Ancient Roman programmers' adage.)
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
From: Howard R. Stearns
Subject: Re: `fast' global variables (Ex: Re: ??: using * for variable ?)
Date:
Message-ID: <36F66BFC.A7EA65D7@elwood.com>
Vassil Nikolov wrote:
> .. .
> I can't do (DEFCONSTANT FOO (MAKE-ARRAY NIL)) and then
> (AREF FOO) for getting the value and (SETF (AREF FOO) value) ;ERROR!
> for setting the value, though perhaps it would have been nice if
> I could. ...
Why not?
I don't beleive that the object which is the value of a defconstant is
to be considered immutable, only the binding itself.
If you want to do (setf (aref foo index) value), you can't do:
(defconstant foo '#(1 2 3))
or
(defconstant foo (load-time-value (make-array 3 :initial-contents '(1 2
3) t))
....or similarly for (defvar foo ...), but that's because of the
immutability of the value, not the binding.
From: Kent M Pitman
Subject: Re: `fast' global variables (Ex: Re: ??: using * for variable ?)
Date:
Message-ID: <sfwbthlqshb.fsf@world.std.com>
"Howard R. Stearns" <······@elwood.com> writes:
>
> Vassil Nikolov wrote:
> > .. .
> > I can't do (DEFCONSTANT FOO (MAKE-ARRAY NIL)) and then
> > (AREF FOO) for getting the value and (SETF (AREF FOO) value) ;ERROR!
> > for setting the value, though perhaps it would have been nice if
> > I could. ...
>
> Why not?
> I don't beleive that the object which is the value of a defconstant is
> to be considered immutable, only the binding itself.
I think it's immutable. I don't have a cite offhand, but I'll hunt around.
I think you have to say DEFPARAMETER if you don't want the compiler to
treat it like a literal constant.
> If you want to do (setf (aref foo index) value), you can't do:
> (defconstant foo '#(1 2 3))
> or
> (defconstant foo (load-time-value (make-array 3 :initial-contents '(1 2
> 3) t))
> ....or similarly for (defvar foo ...), but that's because of the
> immutability of the value, not the binding.
I don't think this makes any sense. defconstant exists to allow compile-time
resolution. saying to make the thing at load-time is more like nesting
eval-when of :load-toplevel inside an eval-when of :compile-toplevel.
The nesting isn't intuitive.
From: Vassil Nikolov
Subject: Re: `fast' global variables (Ex: Re: ??: using * for variable ?)
Date:
Message-ID: <7d6dtj$bp0$1@nnrp1.dejanews.com>
In article <···············@world.std.com>,
Kent M Pitman <······@world.std.com> wrote:
> "Howard R. Stearns" <······@elwood.com> writes:
>
> >
> > Vassil Nikolov wrote:
> > > .. .
> > > I can't do (DEFCONSTANT FOO (MAKE-ARRAY NIL)) and then
> > > (AREF FOO) for getting the value and (SETF (AREF FOO) value) ;ERROR!
> > > for setting the value, though perhaps it would have been nice if
> > > I could. ...
> >
> > Why not?
> > I don't beleive that the object which is the value of a defconstant is
> > to be considered immutable, only the binding itself.
>
> I think it's immutable. I don't have a cite offhand, but I'll hunt
> around.
This time I have the exact reference. I also used to think that just
the binding was immutable (and maybe it was that way in CLtL, 1st ed.),
but then I read that:
3.2.2.3 Semantic Constraints
(...)
Constant variables defined in the compilation environment must have a
similar value at run time. A reference to a constant variable in source
code is equivalent to a reference to a literal object that is the value
of the constant variable.
(Well, as Humpty Dumpty said, `There's glory for us!')
So
(defconstant bad-foo (make-array nil) "single-slot")
(setf (aref bad-foo) 'bar)
is in error.
> I think you have to say DEFPARAMETER if you don't want the compiler to
> treat it like a literal constant.
Yes, but DEFPARAMETER is no different from DEFVAR with respect to being
fast or slow in lookup of the variable's value, so DEFPARAMETER was of
no interest to me for the purpose of this particular (self-imposed)
exercise.
Vassil Nikolov <········@poboxes.com> www.poboxes.com/vnikolov
(You may want to cc your posting to me if I _have_ to see it.)
LEGEMANVALEMFVTVTVM (Ancient Roman programmers' adage.)
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
In article <············@nnrp1.dejanews.com>,
Vassil Nikolov <········@poboxes.com> writes:
> In article <···············@world.std.com>,
> Kent M Pitman <······@world.std.com> wrote:
>> "Howard R. Stearns" <······@elwood.com> writes:
>>
>> >
>> > Vassil Nikolov wrote:
>> > > .. .
>> > > I can't do (DEFCONSTANT FOO (MAKE-ARRAY NIL)) and then
>> > > (AREF FOO) for getting the value and (SETF (AREF FOO) value) ;ERROR!
>> > > for setting the value, though perhaps it would have been nice if
>> > > I could. ...
>> >
>> > Why not?
>> > I don't beleive that the object which is the value of a defconstant is
>> > to be considered immutable, only the binding itself.
>>
>> I think it's immutable. I don't have a cite offhand, but I'll hunt
>> around.
>
> This time I have the exact reference. I also used to think that just
> the binding was immutable (and maybe it was that way in CLtL, 1st ed.),
> but then I read that:
>
> 3.2.2.3 Semantic Constraints
> (...)
> Constant variables defined in the compilation environment must have a
> similar value at run time. A reference to a constant variable in source
> code is equivalent to a reference to a literal object that is the value
> of the constant variable.
It says the object, not the contents of the object. To me, this means that
the variable binding is immutable, not the object itsself. Whether someplace
else it says the object's contents are also immutable I don't know. I would
hope not. I thought the purpose of defconstant was so the compiler could infer
the type and size of the object and make optimizations based upon that.
Mike McDonald
·······@mikemac.com
·······@mikemac.com (Mike McDonald) writes:
> It says the object, not the contents of the object. To me, this means that
> the variable binding is immutable, not the object itsself. Whether someplace
> else it says the object's contents are also immutable I don't know. I would
> hope not. I thought the purpose of defconstant was so the compiler could infer
> the type and size of the object and make optimizations based upon that.
>
> Mike McDonald
> ·······@mikemac.com
The problem is a little different than that, actually. I believe you are
perfectly in line if you want to modify the contents of the object. But in
one program that is what I was relying on, and wrote code like this:
In one file:
(defconstant +eof+ (list nil))
In another:
(read foo-stream nil nil +eof+)
(I believe that is the right syntax for reading from a stream and having it
return an object rather than signal an error on EOF. In any case, that's
irrelevant to the point.)
Worked as expected in lispworks, but MCL barfed. Apparently, a possible
interpretation of the standard is that the values of contants do not have
to remain eq to each other across different source files. I forget the
exact reasoning, but that is what it came down to. Digitool advised me to
change over to defvar to get around this problem.
In other words, an implementation conforms to the standard if it
re-evaluates and reconstructs a constant's value in each source file. The
idea for the fast global variable, in other words, is not guaranteed to
work in all implementations.
Sunil
In article <···············@whizzy.cc.gatech.edu> , Sunil Mishra
<·······@whizzy.cc.gatech.edu> wrote:
[snip]
> The problem is a little different than that, actually. I believe you are
> perfectly in line if you want to modify the contents of the object. But in
> one program that is what I was relying on, and wrote code like this:
>
> In one file:
>
> (defconstant +eof+ (list nil))
>
> In another:
>
> (read foo-stream nil nil +eof+)
>
> (I believe that is the right syntax for reading from a stream and having it
> return an object rather than signal an error on EOF. In any case, that's
> irrelevant to the point.)
>
> Worked as expected in lispworks, but MCL barfed. Apparently, a possible
> interpretation of the standard is that the values of contants do not have
> to remain eq to each other across different source files. I forget the
> exact reasoning, but that is what it came down to. Digitool advised me to
> change over to defvar to get around this problem.
>
> In other words, an implementation conforms to the standard if it
> re-evaluates and reconstructs a constant's value in each source file. The
> idea for the fast global variable, in other words, is not guaranteed to
> work in all implementations.
I don't know whether this was true at some point, but the following text in
the ANSI spec contradicts your interpretation.
"The side effects of the execution of defconstant must be equivalent to at
least the side effects of the execution of the following code:
(setf (symbol-value 'name) initial-value)
(setf (documentation 'name 'variable) 'documentation)"
--
David B. Lamkins <http://www.teleport.com/~dlamkins/>
From: Sunil Mishra
Subject: Re: `fast' global variables (Ex: Re: ??: using * for variable ?)
Date:
Message-ID: <efyiubszumt.fsf@cleon.cc.gatech.edu>
"David B. Lamkins" <········@teleport.com> writes:
> I don't know whether this was true at some point, but the following text in
> the ANSI spec contradicts your interpretation.
>
> "The side effects of the execution of defconstant must be equivalent to at
> least the side effects of the execution of the following code:
>
> (setf (symbol-value 'name) initial-value)
> (setf (documentation 'name 'variable) 'documentation)"
OK, let me try and recall a somewhat distorted (since I was a newbie when I
was exposed to this argument) version of the argument.
Consider (defconstant *foo* '(())). There are two ways to look at this
constant. The constant exists independent of the source code is one. The
alternative is that the constant is subject to the compile time
environment. As I understand it, the compile time environment does not have
to be the same as the run time environment, which is where forms such as
eval-when come in and play a role. While compiling therefore an
implementation is allowed to reconstruct the value of a constant, rather
than obtain it from some globally correct value. In other words, while
compiling the implementation is allowed to substitute in the value of a
constant and then produce a fasl, rather than look up the value in the
current run-time environment when the compiled code is loaded.
Effectively, this produces a situation where the constant does not preserve
its value across source files. So while the defconstant behaves as the spec
dictates, the result of compiling code containing the constant is counter-
intuitive.
Again, this is coming down through mists of time and ignorance, so a better
informed comment would be very useful.
Sunil
In article <···············@cleon.cc.gatech.edu> , Sunil Mishra
<·······@cleon.cc.gatech.edu> wrote:
> "David B. Lamkins" <········@teleport.com> writes:
>
>
>> I don't know whether this was true at some point, but the following text in
>> the ANSI spec contradicts your interpretation.
>>
>> "The side effects of the execution of defconstant must be equivalent to at
>> least the side effects of the execution of the following code:
>>
>> (setf (symbol-value 'name) initial-value)
>> (setf (documentation 'name 'variable) 'documentation)"
>
> OK, let me try and recall a somewhat distorted (since I was a newbie when I
> was exposed to this argument) version of the argument.
>
> Consider (defconstant *foo* '(())). There are two ways to look at this
> constant. The constant exists independent of the source code is one. The
> alternative is that the constant is subject to the compile time
> environment. As I understand it, the compile time environment does not have
> to be the same as the run time environment, which is where forms such as
> eval-when come in and play a role. While compiling therefore an
> implementation is allowed to reconstruct the value of a constant, rather
> than obtain it from some globally correct value. In other words, while
> compiling the implementation is allowed to substitute in the value of a
> constant and then produce a fasl, rather than look up the value in the
> current run-time environment when the compiled code is loaded.
>
> Effectively, this produces a situation where the constant does not preserve
> its value across source files. So while the defconstant behaves as the spec
> dictates, the result of compiling code containing the constant is counter-
> intuitive.
>
> Again, this is coming down through mists of time and ignorance, so a better
> informed comment would be very useful.
Ahh, I see. I understand the argument, and it seems intuitive, but I'd like
to get the CLHS to agree. Here's what I came up with:
Later in the description of defconstant, CLHS says:
"An implementation may choose to evaluate the value-form at compile time,
load time, or both. Therefore, users must ensure that the initial-value can
be evaluated at compile time (regardless of whether or not references to
name appear in the file) and that it always evaluates to the same value."
The CLHS glossary defines "same" as follows (eliding irrelevant
sub-definitions):
"same adj. [...] 2. (of objects if no predicate is implied by context)
indistinguishable by eql. Note that eq might be capable of distinguishing
some numbers and characters which eql cannot distinguish, but the nature of
such, if any, is implementation-dependent. Since eq is used only rarely in
this specification, eql is the default predicate when none is mentioned
explicitly. ``The conses returned by two successive calls to cons are never
the same.'' [...]"
The first sentence seems applicable, since no context (i.e. no statement of
the form "... the same under <predicate>") is given in the definition of
defconstant.
Backing up a bit, I notice the phrase "users must ensure ... and that it
always evaluates to the same value."
Combining this with the final sentence (two conses never the same) of the
"same" glossary entry quoted above, I think I see how your example's
behavior is allowed: If I create a program containing the form
(defconstant *foo* '(()))
then I have failed to ensure that the initial value is the same at compile
time and load time. If the implementation evaluates the defconstant form at
both compile and load time, it will cons two different initial values.
So, now for the $2^16 question: Have I interpreted this correctly?
--
David B. Lamkins <http://www.teleport.com/~dlamkins/>
From: Steven M. Haflich
Subject: Re: `fast' global variables (Ex: Re: ??: using * for variable ?)
Date:
Message-ID: <36F7E87F.F4BC4B8F@franz.com>
David B. Lamkins wrote:
> Combining this with the final sentence (two conses never the same) of the
> "same" glossary entry quoted above, I think I see how your example's
> behavior is allowed: If I create a program containing the form
> (defconstant *foo* '(()))
> then I have failed to ensure that the initial value is the same at compile
> time and load time. If the implementation evaluates the defconstant form at
> both compile and load time, it will cons two different initial values.
>
> So, now for the $2^16 question: Have I interpreted this correctly?
Sorry, no.
The glitch in your analysis is that the constant list in your form is not
constructed by evaluation. It is constructed once, by the reader. (That's
what QUOTE means: Don't evaluate the subform. :-)
Now, the problem of capturing multiple non-eq versions of a constant
arises only when the constant is captured in separately-compiled files.
Lacking any persistent database in which to store constants, _if_ the
file compiler choses to dereference a constant variable at compile time,
there is no way for it to preserve equivalence. That is why the ACL
compiler only dereferences constants like numbers and symbols.
The best CL idiom to deal with these things is to use LOAD-TIME-VALUE.
Assuming that evaluating a global variable is slightly more expensive
than retrieving a constant, the reference would be something like:
(read stream nil (load-time-value +eof+))
Now, what you'd really like is something like the following (untested, for
reasons that will become clear):
(defmacro defconstant* (symbol value &rest rest)
`(progn
(defconstant ,symbol ,value ,@rest)
(define-symbol-macro ,symbol (load-time-value (symbol-value ',symbol)))))
Unfortunately, this possibility is specifically excluded by the ANS. It is
illegal to define a global symbol macro on a symbol declared as a global
variable. Perhaps this restriction was a mistake.
A smart compiler could still provide this service for you behind your back.
It's something we might consider...
From: Vassil Nikolov
Subject: Re: `fast' global variables (Ex: Re: ??: using * for variable ?)
Date:
Message-ID: <7d9hij$1a9$1@nnrp1.dejanews.com>
In article <·················@franz.com>,
"Steven M. Haflich" <···@franz.com> wrote:
(...)
> illegal to define a global symbol macro on a symbol declared as a global
> variable. Perhaps this restriction was a mistake.
(...)
I don't think so.
Imagine a book which says, perhaps in an obscure footnote, let e be
<some value which is not exp 0>, and then uses e^x throughout.
Vassil Nikolov <········@poboxes.com> www.poboxes.com/vnikolov
(You may want to cc your posting to me if I _have_ to see it.)
LEGEMANVALEMFVTVTVM (Ancient Roman programmers' adage.)
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
From: Lieven Marchand
Subject: Re: `fast' global variables (Ex: Re: ??: using * for variable ?)
Date:
Message-ID: <m390cmmwby.fsf@localhost.localdomain>
Vassil Nikolov <········@poboxes.com> writes:
> In article <·················@franz.com>,
> "Steven M. Haflich" <···@franz.com> wrote:
> (...)
> > illegal to define a global symbol macro on a symbol declared as a global
> > variable. Perhaps this restriction was a mistake.
> (...)
>
> I don't think so.
>
> Imagine a book which says, perhaps in an obscure footnote, let e be
> <some value which is not exp 0>, and then uses e^x throughout.
>
I'd like it to be (exp 1) if you don't mind ;-)
--
Lieven Marchand <···@bewoner.dma.be>
If there are aliens, they play Go. -- Lasker
From: Vassil Nikolov
Subject: Re: `fast' global variables (Ex: Re: ??: using * for variable ?)
Date:
Message-ID: <7dei3e$dm8$1@nnrp1.dejanews.com>
In article <··············@localhost.localdomain>,
Lieven Marchand <···@bewoner.dma.be> wrote:
> Vassil Nikolov <········@poboxes.com> writes:
>
> > In article <·················@franz.com>,
> > "Steven M. Haflich" <···@franz.com> wrote:
> > (...)
> > > illegal to define a global symbol macro on a symbol declared as a global
> > > variable. Perhaps this restriction was a mistake.
> > (...)
> >
> > I don't think so.
> >
> > Imagine a book which says, perhaps in an obscure footnote, let e be
> > <some value which is not exp 0>, and then uses e^x throughout.
> >
>
> I'd like it to be (exp 1) if you don't mind ;-)
';-)' indeed---my mistake turns out to be more correct than it seems:
I did have `exp 1' (or `exp exp 0') in mind when I wrote it, but now
I see `exp 0' is really what I want, because it would be silly to
say `e^x' for e=1, and it's clear that <some value ...> would not be
exp 1.
Well, in fact the amount of words required increases with the precision
one wants to attain, since what I really want there is <some value which
is neither 0, 1, nor exp 1, unless we deal in real numbers only, when
it must be a positive real other than 1 or exp 1>. Grrrrrrrrrr...
Vassil Nikolov <········@poboxes.com> www.poboxes.com/vnikolov
(You may want to cc your posting to me if I _have_ to see it.)
LEGEMANVALEMFVTVTVM (Ancient Roman programmers' adage.)
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
From: Vassil Nikolov
Subject: Re: `fast' global variables (Ex: Re: ??: using * for variable ?)
Date:
Message-ID: <7d9923$q81$1@nnrp1.dejanews.com>
In article <······················@news1.teleport.com>,
"David B. Lamkins" <········@teleport.com> wrote:
(...)
> "same adj. [...] 2.
(...)
> Backing up a bit, I notice the phrase "users must ensure ... and that it
> always evaluates to the same value."
>
> Combining this with the final sentence (two conses never the same) of the
> "same" glossary entry quoted above, I think I see how your example's
> behavior is allowed: If I create a program containing the form
> (defconstant *foo* '(()))
> then I have failed to ensure that the initial value is the same at compile
> time and load time. If the implementation evaluates the defconstant form at
> both compile and load time, it will cons two different initial values.
>
> So, now for the $2^16 question: Have I interpreted this correctly?
The word we need here is `similar.'
Vassil Nikolov <········@poboxes.com> www.poboxes.com/vnikolov
(You may want to cc your posting to me if I _have_ to see it.)
LEGEMANVALEMFVTVTVM (Ancient Roman programmers' adage.)
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
From: Kent M Pitman
Subject: Re: `fast' global variables (Ex: Re: ??: using * for variable ?)
Date:
Message-ID: <sfwyaknu3qz.fsf@world.std.com>
"David B. Lamkins" <········@teleport.com> writes:
> Combining this with the final sentence (two conses never the same) of the
> "same" glossary entry quoted above, I think I see how your example's
> behavior is allowed: If I create a program containing the form
> (defconstant *foo* '(()))
> then I have failed to ensure that the initial value is the same at compile
> time and load time. If the implementation evaluates the defconstant form at
> both compile and load time, it will cons two different initial values.
>
> So, now for the $2^16 question: Have I interpreted this correctly?
(That's guaranteed not to be big bucks, though, isn't it? :-)
I think most of your interpretation is correct except I don't think it
says enough things to
support Sunil's conclusion, even though I think Sunil's right.
I think the facts you need to cite are not just that it
works as you say and htat you didn't provide protect yourself but also
that you were forbidden to for conses. (Can't write a make-load-form
on them.) It seems to me that if you'd done
(defconstant +foo+ ;I don't like *'s around constants.
(get-canonical-copy '(())))
where you'd grabbed the copy out of a registry you wouldn't be accepting
just any old item in either case, but a trusted copy with some sense
of identity, and you'd have the same questions you had before.
And you'd still lose because if someone saved this set, it wouldn't get
written out in a way that called get-canonical-copy again because there
is no association between the object's identity and the manner of its
creation or lookup.
HOWEVER, with user-defined classes that's not so. You *could* have
MAKE-LOAD-FORMS such that even if the compiler wrote out the constant
in two different places it would have enough info to repatriate the
constant with all the other copies and with the things the copy was
supposed to deal with. But that's just the definition of
similarity... that you write a make-load-form method to make the
thing be similar.
So it's really an argument of practicality and externalizable objects
that leads you to where you want to be.
From: Erik Naggum
Subject: Re: `fast' global variables (Ex: Re: ??: using * for variable ?)
Date:
Message-ID: <3131135071149992@naggum.no>
* ANSI X3.226-1994
| 3.2.2.3 Semantic Constraints
| (...)
| Constant variables defined in the compilation environment must have a
| similar value at run time. A reference to a constant variable in source
| code is equivalent to a reference to a literal object that is the value
| of the constant variable.
* ·······@mikemac.com (Mike McDonald)
| It says the object, not the contents of the object.
I think you need to look up `literal object':
literal adj. (of an object) referenced directly in a program rather than
being computed by the program; that is, appearing as data in a quote form,
or, if the object is a self-evaluating object, appearing as unquoted data.
``In the form (cons "one" '("two")), the expressions "one", ("two"), and
"two" are literal objects.''
such objects are immutable:
constant object n. an object that is constrained (e.g., by its context in a
program or by the source from which it was obtained) to be immutable. ``A
literal object that has been processed by compile-file is a constant object.''
#:Erik
In article <················@naggum.no>,
Erik Naggum <····@naggum.no> writes:
> * ANSI X3.226-1994
>| 3.2.2.3 Semantic Constraints
>| (...)
>| Constant variables defined in the compilation environment must have a
>| similar value at run time. A reference to a constant variable in source
>| code is equivalent to a reference to a literal object that is the value
>| of the constant variable.
>
> * ·······@mikemac.com (Mike McDonald)
>| It says the object, not the contents of the object.
>
> I think you need to look up `literal object':
>
> literal adj. (of an object) referenced directly in a program rather than
> being computed by the program; that is, appearing as data in a quote form,
> or, if the object is a self-evaluating object, appearing as unquoted data.
> ``In the form (cons "one" '("two")), the expressions "one", ("two"), and
> "two" are literal objects.''
>
> such objects are immutable:
>
> constant object n. an object that is constrained (e.g., by its context in a
> program or by the source from which it was obtained) to be immutable. ``A
> literal object that has been processed by compile-file is a constant object.''
>
> #:Erik
So the (hyper) spec uses "constant object" for immutable things. defconstant
doesn't signify that the object is constant, only that using the binding of the
symbol has to be equivilent to using the literal form.
Mike McDonald
·······@mikemac.com
From: Vassil Nikolov
Subject: Re: `fast' global variables (Ex: Re: ??: using * for variable ?)
Date:
Message-ID: <7d99op$qqu$1@nnrp1.dejanews.com>
In article <············@spitting-spider.aracnet.com>,
·······@mikemac.com wrote:
> In article <················@naggum.no>,
> Erik Naggum <····@naggum.no> writes:
> > * ANSI X3.226-1994
> >| 3.2.2.3 Semantic Constraints
> >| (...)
> >| Constant variables defined in the compilation environment must have a
> >| similar value at run time. A reference to a constant variable in source
> >| code is equivalent to a reference to a literal object that is the value
> >| of the constant variable.
> >
> > * ·······@mikemac.com (Mike McDonald)
> >| It says the object, not the contents of the object.
> >
> > I think you need to look up `literal object':
> >
> > literal adj. (of an object) referenced directly in a program rather than
> > being computed by the program; that is, appearing as data in a quote form,
> > or, if the object is a self-evaluating object, appearing as unquoted data.
> > ``In the form (cons "one" '("two")), the expressions "one", ("two"), and
> > "two" are literal objects.''
> >
> > such objects are immutable:
> >
> > constant object n. an object that is constrained (e.g., by its context in a
> > program or by the source from which it was obtained) to be immutable. ``A
> > literal object that has been processed by compile-file is a constant object.''
> >
> > #:Erik
>
> So the (hyper) spec uses "constant object" for immutable things. defconstant
> doesn't signify that the object is constant, only that using the binding of the
> symbol has to be equivilent to using the literal form.
Consider then the following example:
(defconstant c '(some value) "example")
(let ((local-var '(some value)))
... ;with local-var appearing in a for-evaluation position here
And we have a reference to C somewhere in the program which is
equivalent to a reference to '(SOME VALUE).
Now, what is `a reference to a literal object that is the value
of the constant variable'? Is it (1) like the reference to LOCAL-VAR
in the LET, or is it (2) like '(SOME VALUE) appearing literally in a
for-evaluation position, or is there a third possibility?
If (1), then `is equivalent' in the excerpt from 3.2.2.3
is strange, because the binding of LOCAL-VAR is not constant.
You deny (2). So what is the third possibility?
Vassil Nikolov <········@poboxes.com> www.poboxes.com/vnikolov
(You may want to cc your posting to me if I _have_ to see it.)
LEGEMANVALEMFVTVTVM (Ancient Roman programmers' adage.)
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
From: Erik Naggum
Subject: Re: `fast' global variables (Ex: Re: ??: using * for variable ?)
Date:
Message-ID: <3131171314435096@naggum.no>
* ·······@mikemac.com (Mike McDonald)
| So the (hyper) spec uses "constant object" for immutable things.
| defconstant doesn't signify that the object is constant, only that using
| the binding of the symbol has to be equivilent to using the literal form.
and? what part of "literal" don't you get?
#:Erik
In article <················@naggum.no>,
Erik Naggum <····@naggum.no> writes:
> * ·······@mikemac.com (Mike McDonald)
>| So the (hyper) spec uses "constant object" for immutable things.
>| defconstant doesn't signify that the object is constant, only that using
>| the binding of the symbol has to be equivilent to using the literal form.
>
> and? what part of "literal" don't you get?
>
> #:Erik
The part where you're adding the immutable to it. At least in the hyper
spec's glossary, which you quoted, it does NOT say literal objects are
immutable. A literal object is that one, unique object. It says nothing about
the status of its contents. In their example of '("two"), it's the cons cell
that is the literal object being refered to, not the string "two" or the NIL
on the end. Granted, in this example, you'd confuse most people by replaca-ing
the list, but I don't see anything in this definition that it says you can't.
In every case where I've seen (defconstant *foo* (make-array ...)) used,
what was intended that *foo* would always point to the same array, not that
the array's contents would always be the same. But heck, with MCL's
interpretation that it can be a different array in every compiled file,
DEFCONSTANT doesn't mean anything useable.
Mike McDonald
·······@mikemac.com
From: Tim Bradshaw
Subject: Re: `fast' global variables (Ex: Re: ??: using * for variable ?)
Date:
Message-ID: <nkjaex457z3.fsf@tfeb.org>
·······@mikemac.com (Mike McDonald) writes:
> The part where you're adding the immutable to it. At least in the hyper
> spec's glossary, which you quoted, it does NOT say literal objects are
> immutable. A literal object is that one, unique object. It says nothing about
> the status of its contents. In their example of '("two"), it's the cons cell
> that is the literal object being refered to, not the string "two" or the NIL
> on the end. Granted, in this example, you'd confuse most people by replaca-ing
> the list, but I don't see anything in this definition that it says you can't.
I think that a quoted list like that *is* immutable in fact. I had a
whole issue recently to do with students getting confused about this
and I and others did some reading of the spec and that's my current
opinion on its reading (conveniantly, because that's what I though
anyway ...). It is certainly a sensible restriction that it *should*
be immutable because it allows lots of nice optimisations and forbids
various hideous programming styles (altering quoted structure
appearing in the text of code).
I am surprised that the value of something defined with DEFCONSTANT is
immutable, though that seems to be a plausible reading of the spec
(and I can kind of see why it should be like that, because of all the
issues with compileload/runtime sameness. I think it's a misfeature
though, because allowing the values to be mutable is just so useful.
I'd really like someone who understands all the issues better to
explain this to me actually -- how hard would it be to make
DEFCONSTANT do (what I think is) the right thing?
--tim
In article <···············@tfeb.org>,
Tim Bradshaw <···@tfeb.org> writes:
> ·······@mikemac.com (Mike McDonald) writes:
>
>
>> The part where you're adding the immutable to it. At least in the hyper
>> spec's glossary, which you quoted, it does NOT say literal objects are
>> immutable. A literal object is that one, unique object. It says nothing about
>> the status of its contents. In their example of '("two"), it's the cons cell
>> that is the literal object being refered to, not the string "two" or the NIL
>> on the end. Granted, in this example, you'd confuse most people by replaca-ing
>> the list, but I don't see anything in this definition that it says you can't.
>
> I think that a quoted list like that *is* immutable in fact.
Could be (and probably shoould be although I've never seen an immutable cons
cell before). But that's a separate issue from what a "literal" is.
> I am surprised that the value of something defined with DEFCONSTANT is
> immutable, though that seems to be a plausible reading of the spec
Well you should be surprised since no one has been able to show that the
spec says that.
> (and I can kind of see why it should be like that, because of all the
> issues with compileload/runtime sameness.
That's a different issue. What it means is that if in one file I have
(defconstant *foo* (make-array 10))
(defun baz ()
(print (eql *foo* (bar))))
and in another file I have
(defun bar ()
*foo*)
then what gets printed out when BAZ is called can be either T or NIL.
(Because the *foo* in BAR may have gotten the value from a different
environment. Now, if you had used DEFVAR instead, it'd always print the
expected T. Kind of counter intuitive that DEFVAR's are EQ but DEFCONSTANTs
aren't necessarily.)
> how hard would it be to make
> DEFCONSTANT do (what I think is) the right thing?
>
> --tim
I contend the spec already says it does work that way.
Mike McDonald
·······@mikemac.com
From: Tim Bradshaw
Subject: Re: `fast' global variables (Ex: Re: ??: using * for variable ?)
Date:
Message-ID: <nkj7ls7u94p.fsf@tfeb.org>
·······@mikemac.com (Mike McDonald) writes:
>
> (defconstant *foo* (make-array 10))
>
> (defun baz ()
> (print (eql *foo* (bar))))
>
> and in another file I have
>
> (defun bar ()
> *foo*)
>
> then what gets printed out when BAZ is called can be either T or NIL.
> (Because the *foo* in BAR may have gotten the value from a different
> environment. Now, if you had used DEFVAR instead, it'd always print the
> expected T. Kind of counter intuitive that DEFVAR's are EQ but DEFCONSTANTs
> aren't necessarily.)
>
Can you demonstrate that this is legal behaviour? (Not that some
implementation has it.)
--tim
In article <···············@tfeb.org>,
Tim Bradshaw <···@tfeb.org> writes:
> ·······@mikemac.com (Mike McDonald) writes:
>
>>
>> (defconstant *foo* (make-array 10))
>>
>> (defun baz ()
>> (print (eql *foo* (bar))))
>>
>> and in another file I have
>>
>> (defun bar ()
>> *foo*)
>>
>> then what gets printed out when BAZ is called can be either T or NIL.
>> (Because the *foo* in BAR may have gotten the value from a different
>> environment. Now, if you had used DEFVAR instead, it'd always print the
>> expected T. Kind of counter intuitive that DEFVAR's are EQ but DEFCONSTANTs
>> aren't necessarily.)
>>
>
> Can you demonstrate that this is legal behaviour? (Not that some
> implementation has it.)
>
> --tim
I think it goes something like this:
compile and load file 1
compile and load file 2 ; BAR has the same value for *FOO*
compile and load file 1 ; BAZ has a new value for *FOO*!
Mike McDonald
·······@mikemac.com
From: Vassil Nikolov
Subject: Re: `fast' global variables (Ex: Re: ??: using * for variable ?)
Date:
Message-ID: <7d9d58$tng$1@nnrp1.dejanews.com>
In article <············@spitting-spider.aracnet.com>,
·······@mikemac.com wrote:
(...)
> At least in the hyper
> spec's glossary, which you quoted, it does NOT say literal objects are
> immutable.
(...)
Once again, see Section 3.7.1.
> In every case where I've seen (defconstant *foo* (make-array ...)) used,
> what was intended that *foo* would always point to the same array, not that
> the array's contents would always be the same. But heck, with MCL's
> interpretation that it can be a different array in every compiled file,
> DEFCONSTANT doesn't mean anything useable.
May every case have been CLtL 1st ed. usage?
<opening the book>
Sorry, no, even in the 1st ed. text in the 2nd ed. (p. 87),
`(...) the compiler chooses to replace references to the name of the
constant by the value of the constant in code to be compiled (...),'
I shouldn't be guessing.
And what's MCL done to you? Does it not obey the standard? Does
it introduce copies of constants that are not similar?
Vassil Nikolov <········@poboxes.com> www.poboxes.com/vnikolov
(You may want to cc your posting to me if I _have_ to see it.)
LEGEMANVALEMFVTVTVM (Ancient Roman programmers' adage.)
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
From: Kent M Pitman
Subject: Re: `fast' global variables (Ex: Re: ??: using * for variable ?)
Date:
Message-ID: <sfwww07u2z9.fsf@world.std.com>
·······@mikemac.com (Mike McDonald) writes:
> The part where you're adding the immutable to it. At least in the hyper
> spec's glossary, which you quoted, it does NOT say literal objects are
> immutable.
That's because, as I understand it, literal objects are not immutable.
But literal objects seen by the file compiler are.
In particular, I think:
(let ((x (list nil)))
(compile nil `(lambda () ',x)))
returns a function that yields a modifiable literal. It is the process
of externalization, not the process of semantic processing per se, that
renders an object immutable. As I recall, anyway.
There is an ordering problem here in the design of the language. We
reached this conclusion after much debate because we didn't yet have
LOAD-TIME-VALUE. We later added LOAD-TIME-VALUE because this matter
was so confusing and contentious but we didn't go back and clean up the
mess in EVAL. Now that there's LOAD-TIME-VALUE there is no essential
reason that all quoted things couldn't be immutable. But in the pre
LOAD-TIME-VALUE days there was an important efficiency reason why it
was important that code be able to return a "literal" that was still
"mutable" even if such code had to be itself created at loadtime in
"impure space" (or whatever they call data on non-read-only pages
these days.
> A literal object is that one, unique object. It says nothing about
> the status of its contents. In their example of '("two"), it's the
> cons cell that is the literal object being refered to, not the
> string "two" or the NIL on the end. Granted, in this example, you'd
> confuse most people by replaca-ing the list, but I don't see
> anything in this definition that it says you can't.
Yes, I agree with this analysis philosophically, though the record is
a bit muddled and both you and Erik are probably slightly confused because
the language itself is slightly confused on this point.
"Sorry about that."
> In every case where I've seen (defconstant *foo* (make-array ...)) used,
> what was intended that *foo* would always point to the same array, not that
> the array's contents would always be the same. But heck, with MCL's
> interpretation that it can be a different array in every compiled file,
> DEFCONSTANT doesn't mean anything useable.
Right. Externalization is a mess. As I recall, an example place
where it matters is in CLOS-like dispatching where you want to AREF
out of a table that can have known address at load time but that still
wants to be mutable to accomodate redefinition. If you require that
it live in a special variable, you have to do what the pdp10 called a
MOVE instruction (an instruction that takes an argument of a memory
location and does a memory read from that location); to access a
quoted constant, you can get away with a MOVEI (immediate move, where
you don't have to do a memory access because you know the "from" value
and can represent it in the code vector instead of in the heap). So,
in principle, (AREF (LOAD-TIME-VALUE ...) I) is possible to make
faster than (AREF +SOME-CONSTANT+ I) because the former can (in
principle) be made a MOVEI, while it's hard to tell how the second
could be any better than a MOVE indirect through +SOME-CONSTANT+'s
value cell (unless you put the value cell in the code vector itself
and there was never more than one such code vector, but that's pretty
odd). I don't know modern instruction sets well enough to know what
the instruction options are, so my apologies for picking such an old
one. Of course, an actual CLOS implementation is probably
system-provided and doesn't have to fuss about this, but if you wanted
to duplicate things CLOS does yourself with no loss of efficiency,
you'd want something this powerful to avoid losing a memory cycle on
some architectures.
From: Erik Naggum
Subject: Re: `fast' global variables (Ex: Re: ??: using * for variable ?)
Date:
Message-ID: <3131270602413412@naggum.no>
* Mike McDonald
| A literal object is that one, unique object. It says nothing about
| the status of its contents. In their example of '("two"), it's the
| cons cell that is the literal object being refered to, not the
| string "two" or the NIL on the end. Granted, in this example, you'd
| confuse most people by replaca-ing the list, but I don't see
| anything in this definition that it says you can't.
* Kent M Pitman <······@world.std.com>
| Yes, I agree with this analysis philosophically, though the record is
| a bit muddled and both you and Erik are probably slightly confused because
| the language itself is slightly confused on this point.
| "Sorry about that."
I'm not quite certain that I see where the supposed confusion lies. if a
compiler is allowed to store literals in pure space in the first place,
why does the string that is the supposed "contents" of a list not granted
the same option? you (or Mike) seem to be saying that given a literal
("foo" "bar") in some variable X, I cannot say (setf (cdr x) '("zot")),
but I _can_ say (setf (char (car x) 0) #\g). this seems too specious to
me to ever want to become an argument I want resolved. that is, I want
it to be resolved at a much higher level: "literals are literals all the
way down".
#:Erik
From: Kent M Pitman
Subject: Re: `fast' global variables (Ex: Re: ??: using * for variable ?)
Date:
Message-ID: <sfwvhfqrit5.fsf@world.std.com>
Erik Naggum <····@naggum.no> writes:
> * Mike McDonald
> | A literal object is that one, unique object. It says nothing about
> | the status of its contents. In their example of '("two"), it's the
> | cons cell that is the literal object being refered to, not the
> | string "two" or the NIL on the end. Granted, in this example, you'd
> | confuse most people by replaca-ing the list, but I don't see
> | anything in this definition that it says you can't.
>
> * Kent M Pitman <······@world.std.com>
> | Yes, I agree with this analysis philosophically, though the record is
> | a bit muddled and both you and Erik are probably slightly confused because
> | the language itself is slightly confused on this point.
> | "Sorry about that."
>
> I'm not quite certain that I see where the supposed confusion lies. if a
> compiler is allowed to store literals in pure space in the first place,
> why does the string that is the supposed "contents" of a list not granted
> the same option? you (or Mike) seem to be saying that given a literal
> ("foo" "bar") in some variable X, I cannot say (setf (cdr x) '("zot")),
> but I _can_ say (setf (char (car x) 0) #\g). this seems too specious to
> me to ever want to become an argument I want resolved. that is, I want
> it to be resolved at a much higher level: "literals are literals all the
> way down".
As far as I know, the compiler is NOT allowed to store literals
anywhere. COMPILE must take literals as they are given and nowhere is
given license to move or coalesce them. It's the file compiler, not
the compiler, and only in its role of externalization (not properly a
"compilation role" but rather a "serialization role") that has license
to engage in coalescing. If you understand coalescing as logically
something that is permitted not at all to even the file compiler and
specifically is permitted to the make-load-form methods of system
classes, then you see the issue better.
I'm saying that lists are treated the same as strings, and that the
identity of neither can be fussed with by the compiler. The compiler is
responsible for treating that object in an "opaque" way, not explicitly
but because no license is given it to do otherwise. All license to coalesce
etc. is given to the fasloader.
At least as I recall. I'm just skimming this mail and don't have time to
do all the reference cites which others seem to be "enjoying" dredging up
anyway.
Whether I'm agreeing with you or with Mike is something I'm trying to stay
clear of. It's not important to me to define my position as in alignment
with one or the other or both or neither. I'm just trying to keep to what
I remember having used to guide me through this mess in the first place.
It's a little like looking at a geological puzzle made by rocks that
have been through several transformations and trying to figure out which
crack and fault shift happened before which other by inspecting the
patterns in the rock and trying to make them line back up. At least I
was there for some of the earthquakes, so I'm hoping my hints will help
even if I don't have full memory.
·······@mikemac.com (Mike McDonald) writes:
> It says the object, not the contents of the object. To me, this
> means that the variable binding is immutable, not the object
> itsself. Whether someplace else it says the object's contents are
> also immutable I don't know. I would hope not.
I don't think it makes any sense for a literal object to contain
non-literals; it wouldn't be literal! Therefore when the spec says
it's a literal object then it has to be literal all the way down.
John Wiseman
From: Howard R. Stearns
Subject: Re: `fast' global variables (Ex: Re: ??: using * for variable ?)
Date:
Message-ID: <36F7C5E0.B61ED835@elwood.com>
I stand corrected. As atonement, let me collect the relevent texts in
one place, demonstrating that the spec does suggest DEFCONSTANT
immutability, but that there is room for improvement. (A cynic might
think that I'm wryly admitting I'm wrong just to show that I really
believe the spec is wrong. A cynic might be right.)
---
There is some question as to whether the values produced by references
to DEFCONSTANT are to be treated as literal objects, and are therefore
immutable.
Two sections indicate that they are to be immutable:
3.2.2.3 Semantic Constraints:
All conforming programs must obey the following constraints: ...
Constant variables defined in the compilation environment must have
a similar value at run time. A reference to a constant variable in
source code is equivalent to a reference to a literal object that is
the value of the constant variable.
"constant object" glossary entry
an object that is constrained (e.g., by its context in a program or
by the source from which it was obtained) to be immutable. "A
literal object that has been processed by compile-file is a constant
object."
Unfortunately, DEFCONSTANT has no direct references to either of these
entries. In fact, nothing related to DEFCONSTANT seems to reference
this "constant object" entry, which itself doesn't even say anything
about actually applying to DEFCONSTANT.
Furthermore, some sections suggest suggest though ommision that the
value of a constant variable is not a constant object or constant
literal, and these sections should probably be ammended:
DEFCONSTANT dictionary entry:
The entry explains in detail the constraints on changing the values of
the constant variable produced by defconstant, when the value might be
computed, and discusses how the variable may not be bound. However,
it never says anything about the value being treated as a literal
object, or about references to internal structures of these values.
3.1.2.1.1.3 Constant Variables:
Certain variables, called constant variables, are reserved as
"named constants." The consequences are undefined if an attempt is
made to assign a value to, or create a binding for a constant
variable, except that a `compatible' redefinition of a constant
variable using defconstant is permitted; see the macro defconstant.
Note that nothing is said about immutability, nor is there any
reference to constant objects or literal objects.
"constant variable" glossary entry:
a variable, the value of which can never change; that is, a
keyword[1] or a named constant. ``The symbols t, nil, :direction, and
most-positive-fixnum are constant variables.''
Nothing is said about immutability. One could argue either that a
value of a variable never changing means that the binding can't
change, or alterantively that the internal structure of the value
cannot be mutated. (There is also no reference to section
3.1.2.1.1.3, which is a shame.)
"named constant" glossary entry:
a variable that is defined by Common Lisp, by the implementation, or
by user code (see the macro defconstant) to always yield the same
value when evaluated. "The value of a named constant may not be
changed by assignment or by binding."
Again, nothing about immutability or treating the value as a literal
object. (Again, no reference to 3.1.2.1.1.3.)
3.2.1 Compiler Terminology:
The term literal object refers to a quoted object or a
self-evaluating object or an object that is a substructure of such
an object. A constant variable is not itself a literal object.
Because this specifically refers to constant variables, but only in
the negative, this could easily be read as indicating that "the value
of a reference to a constant variable is not itself a literal object."
Apparently, the intention is instead to indicate that the conceptual
object called a constant variable (not its value) is not a literal
object. However, it is unusual for the spec to refer to the concept
of a variable as an object.
"literal" glossary entry:
(of an object) referenced directly in a program rather than being
computed by the program; that is, appearing as data in a quote form,
or, if the object is a self-evaluating object, appearing as unquoted
data.
This definition does not include references to a value defined by
DEFCONSTANT.
There is one other source of confusion. Sunil Mishra gives the
example that some implementations might treat the values of
DEFCONSTANT as compile-file literals, with references in different
files being "similar", but not identical. This can lead to confusion.
The "workaround" is to use DEFPARAMETER instead, which leads to the
embarrassing situation that a user might tend to think of the value of
a DEFPARAMETER as more "constant" (really more EQ) across files than
the value of a DEFCONSTANT. This confusion is furthered, as David
Lamkins points out, by generally understanding "similar" to mean EQL.
However, David also points out that the situation only comes up
through "programmer error" because it violates the original citation
from 3.2.2.3, above. (Any misinterpretatin of Sunil's and David's
statements is my fault, not theirs.)
Ultimately, one wonders what is "the right thing." Certainly, one
want to allow compilers to treat the value of a constant variable as
some kind of compile-time literal so that partial evaluation can be
performed at compile time for forms involving references. It comes
down to a quesion of whether DEFCONSTANT constrains both
implementations to make sure that the value was similar at all times,
or just at certain times such as compile and load.
For example, CL already has the issue of what happens when compile
time and run time definitions differ. Consider an expression like:
(FOO BAR)
If FOO is an an inlinable reference to the function -, and bar is a
constant variable with value 1, then the compiler is justified in
treating the entire expression as the literal value -1. This is true
even if the user latter arranges for FOO to have a different function
definition when the above code is actually run. In fact, a different
reference to (FOO BAR) in a context in which FOO may not be inlined,
must actually call the run time definition of FOO, and might produce a
different result.
In other words, we allow the compiler to freeze in the definitions at
compile time, while still allowing a function binding to change when
referenced in a different context. In the case of function bindings,
we're still talking about bindings, not internal structure. (It's
another can of worms as to whether there should be a way to turn of
the constantness of a defconstant BINDING.) The question here is
whether, in the case of DEFCONSTANT, we can allow internal structure
changes to be picked up at run time.
My own inclination is that we have other mechanisms for disallowing
changes to internal structure -- namely quoting and load-time-value --
which could be used in conjunction with the value-form argument to
DEFCONSTANT if desired. Thus, why force defconstant to be a bigger
hammer than it needs to be.
In any case, I think it's clear by now
that any code that relies on an implementation allowing mutations of
value of defconstant will be non-portable, at minimum.
In article <·················@elwood.com>,
"Howard R. Stearns" <······@elwood.com> writes:
> I stand corrected. As atonement, let me collect the relevent texts in
> one place, demonstrating that the spec does suggest DEFCONSTANT
> immutability, but that there is room for improvement. (A cynic might
> think that I'm wryly admitting I'm wrong just to show that I really
> believe the spec is wrong. A cynic might be right.)
>
> ---
> There is some question as to whether the values produced by references
> to DEFCONSTANT are to be treated as literal objects, and are therefore
> immutable.
Where does it say that literal objects are immutable?
> Two sections indicate that they are to be immutable:
>
> 3.2.2.3 Semantic Constraints:
>
> All conforming programs must obey the following constraints: ...
> Constant variables defined in the compilation environment must have
> a similar value at run time. A reference to a constant variable in
> source code is equivalent to a reference to a literal object that is
> the value of the constant variable.
>
> "constant object" glossary entry
>
> an object that is constrained (e.g., by its context in a program or
> by the source from which it was obtained) to be immutable. "A
> literal object that has been processed by compile-file is a constant
> object."
>
> Unfortunately, DEFCONSTANT has no direct references to either of these
> entries. In fact, nothing related to DEFCONSTANT seems to reference
> this "constant object" entry, which itself doesn't even say anything
> about actually applying to DEFCONSTANT.
Because DEFCONSTANT doesn't deal with "constant objects"!
> Furthermore, some sections suggest suggest though ommision that the
> value of a constant variable is not a constant object or constant
> literal, and these sections should probably be ammended:
No it shouldn't! A constant variable is about how an object is bound to a
variable, no more!
> DEFCONSTANT dictionary entry:
>
> The entry explains in detail the constraints on changing the values of
> the constant variable produced by defconstant, when the value might be
> computed, and discusses how the variable may not be bound. However,
> it never says anything about the value being treated as a literal
> object, or about references to internal structures of these values.
Because DEFCONSTANT is only concerned with the binding of the variable!
> 3.1.2.1.1.3 Constant Variables:
>
> Certain variables, called constant variables, are reserved as
> "named constants." The consequences are undefined if an attempt is
> made to assign a value to, or create a binding for a constant
> variable, except that a `compatible' redefinition of a constant
> variable using defconstant is permitted; see the macro defconstant.
>
> Note that nothing is said about immutability, nor is there any
> reference to constant objects or literal objects.
>
> "constant variable" glossary entry:
>
> a variable, the value of which can never change; that is, a
> keyword[1] or a named constant. ``The symbols t, nil, :direction, and
> most-positive-fixnum are constant variables.''
>
> Nothing is said about immutability. One could argue either that a
> value of a variable never changing means that the binding can't
> change, or alterantively that the internal structure of the value
> cannot be mutated. (There is also no reference to section
> 3.1.2.1.1.3, which is a shame.)
>
> "named constant" glossary entry:
>
> a variable that is defined by Common Lisp, by the implementation, or
> by user code (see the macro defconstant) to always yield the same
> value when evaluated. "The value of a named constant may not be
> changed by assignment or by binding."
>
> Again, nothing about immutability or treating the value as a literal
> object. (Again, no reference to 3.1.2.1.1.3.)
Right! Because once again, constant variable and named constant are talking
about the BINDING of a variable, not the object that is being bound.
> "literal" glossary entry:
>
> (of an object) referenced directly in a program rather than being
> computed by the program; that is, appearing as data in a quote form,
> or, if the object is a self-evaluating object, appearing as unquoted
> data.
>
> This definition does not include references to a value defined by
> DEFCONSTANT.
Nor does it say a literal is immutable!
> Ultimately, one wonders what is "the right thing." Certainly, one
> want to allow compilers to treat the value of a constant variable as
> some kind of compile-time literal so that partial evaluation can be
> performed at compile time for forms involving references. It comes
> down to a quesion of whether DEFCONSTANT constrains both
> implementations to make sure that the value was similar at all times,
> or just at certain times such as compile and load.
I've always avoided using DEFCONSTANT because you never were sure about what
value some piece of code had squirreled away. Using DEFCONSTANT leads to
(eql *foo* (some-function-that-always-returns-*foo*)) being able to return NIL
too easily.
> In other words, we allow the compiler to freeze in the definitions at
> compile time, while still allowing a function binding to change when
> referenced in a different context. In the case of function bindings,
> we're still talking about bindings, not internal structure. (It's
> another can of worms as to whether there should be a way to turn of
> the constantness of a defconstant BINDING.) The question here is
> whether, in the case of DEFCONSTANT, we can allow internal structure
> changes to be picked up at run time.
Since DEFCONSTANT, DEFVAR, and DEFPARAMETER are only dealing with
bindings, why would anyone infer that they impose any constraints on modifying
the insides of the bound objects? I always believed that if the spec didn't
explicitly say something was immutable, then assumption was that it was
mutable, especially if functions are provided to do the mutation. Heck, no
place in the hyperspec does it say that MAKE-ARRAY returns a mutable array in
the first place. Would it be "reasonable" then to allow implementations to
only return immutable arrays?
> In any case, I think it's clear by now
> that any code that relies on an implementation allowing mutations of
> value of defconstant will be non-portable, at minimum.
I think any implementation that doesn't is broken.
Mike McDonald
·······@mikemac.com
From: Vassil Nikolov
Subject: literal objects immutable (Ex: Re: `fast' global variables (Ex: Re: ??: using * for variable ?))
Date:
Message-ID: <7d9bgl$sai$1@nnrp1.dejanews.com>
In article <············@spitting-spider.aracnet.com>,
·······@mikemac.com wrote:
(...)
> Where does it say that literal objects are immutable?
Let's try Section 3.7 for a change.
3.7.1 Modification of Literal Objects
The consequences are undefined if literal objects are destructively
modified.
(...)
> Nor does it say a literal is immutable!
Nor does it exhaust what the spec has to say about literals.
(...)
Vassil Nikolov <········@poboxes.com> www.poboxes.com/vnikolov
(You may want to cc your posting to me if I _have_ to see it.)
LEGEMANVALEMFVTVTVM (Ancient Roman programmers' adage.)
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
[Lots of interesting material dug up by Howard not included due to space
considerations.]
As I see it, there are two issues coming up here. One is DEFCONSTANT
immutability, and the other is DEFCONSTANT identity. Not having to preserve
DEFCONSTANT across all the code that is written in an environment can have
a nice efficiency benefit. However, I too find the notion that a constant
may not be EQL across source files I write hard to deal with.
I find it useful to rethink the notion of environments and think of the
role of DEFCONSTANT in those terms. Granted, this may not be realistic, but
it makes a nice thought experiment for me.
Having environments as first class objects, implemented to behave in a
manner analogous to packages, would be nice. In other words, I would like
to be able to say (in-environment "FOO") at the start of my source file. I
would like to be able to define an environment like a package, and be able
to define inheritence across environments. Most importantly, I would like
to be able to write my code knowing that this environment is going to be
available when the code runs or compiles. I know that packages are supposed
to provide much of this separation of data, but AFAIK they don't do much
besides handling name conflicts. I am not proposing turning packges in to
modules. Rather, I would like to see more of a commitment as to what data
they will contain, and how that data will relate to the code that is
executed within the scope of the package.
Incidentally, there is at least one existing system (Matlab) that provides
similar "environments". Matlab has a global environment. The user interacts
with the user environment which is distinct from the global environment,
and any code that is loaded inherits from the user environemnt. Any
references to the global environment have to be explicitly declared. I am
fairly certain that it is possible to specify environments other than the
global in which to look up forms and variables.
Let me add that I haven't thought this through all that much, and I am
throwing it out as a possible topic of discussion, not a concrete proposal.
Sunil
From: Kelly Murray
Subject: Re: `fast' global variables (Ex: Re: ??: using * for variable ?)
Date:
Message-ID: <36F804EA.2696DA@IntelliMarket.Com>
In my opinion, a Defconstant value should be immutable,
so it can be placed in a read-only area, and thus can
be shareable by multiple lisp images.
What gain is there to allow mutability over a Defvar?
Is their some particular problem with having a DefGlobal
which declares a variable global?
-Kelly Murray
Howard R. Stearns wrote:
>
> I stand corrected. As atonement, let me collect the relevent texts in
> one place, demonstrating that the spec does suggest DEFCONSTANT
> immutability, but that there is room for improvement. (A cynic might
> think that I'm wryly admitting I'm wrong just to show that I really
> believe the spec is wrong. A cynic might be right.)
>
> ---
> There is some question as to whether the values produced by references
> to DEFCONSTANT are to be treated as literal objects, and are therefore
> immutable.
>
> Two sections indicate that they are to be immutable:
>
> 3.2.2.3 Semantic Constraints:
>
> All conforming programs must obey the following constraints: ...
> Constant variables defined in the compilation environment must have
> a similar value at run time. A reference to a constant variable in
> source code is equivalent to a reference to a literal object that is
> the value of the constant variable.
>
> "constant object" glossary entry
>
> an object that is constrained (e.g., by its context in a program or
> by the source from which it was obtained) to be immutable. "A
> literal object that has been processed by compile-file is a constant
> object."
>
> Unfortunately, DEFCONSTANT has no direct references to either of these
> entries. In fact, nothing related to DEFCONSTANT seems to reference
> this "constant object" entry, which itself doesn't even say anything
> about actually applying to DEFCONSTANT.
>
> Furthermore, some sections suggest suggest though ommision that the
> value of a constant variable is not a constant object or constant
> literal, and these sections should probably be ammended:
>
> DEFCONSTANT dictionary entry:
>
> The entry explains in detail the constraints on changing the values of
> the constant variable produced by defconstant, when the value might be
> computed, and discusses how the variable may not be bound. However,
> it never says anything about the value being treated as a literal
> object, or about references to internal structures of these values.
>
> 3.1.2.1.1.3 Constant Variables:
>
> Certain variables, called constant variables, are reserved as
> "named constants." The consequences are undefined if an attempt is
> made to assign a value to, or create a binding for a constant
> variable, except that a `compatible' redefinition of a constant
> variable using defconstant is permitted; see the macro defconstant.
>
> Note that nothing is said about immutability, nor is there any
> reference to constant objects or literal objects.
>
> "constant variable" glossary entry:
>
> a variable, the value of which can never change; that is, a
> keyword[1] or a named constant. ``The symbols t, nil, :direction, and
> most-positive-fixnum are constant variables.''
>
> Nothing is said about immutability. One could argue either that a
> value of a variable never changing means that the binding can't
> change, or alterantively that the internal structure of the value
> cannot be mutated. (There is also no reference to section
> 3.1.2.1.1.3, which is a shame.)
>
> "named constant" glossary entry:
>
> a variable that is defined by Common Lisp, by the implementation, or
> by user code (see the macro defconstant) to always yield the same
> value when evaluated. "The value of a named constant may not be
> changed by assignment or by binding."
>
> Again, nothing about immutability or treating the value as a literal
> object. (Again, no reference to 3.1.2.1.1.3.)
>
> 3.2.1 Compiler Terminology:
>
> The term literal object refers to a quoted object or a
> self-evaluating object or an object that is a substructure of such
> an object. A constant variable is not itself a literal object.
>
> Because this specifically refers to constant variables, but only in
> the negative, this could easily be read as indicating that "the value
> of a reference to a constant variable is not itself a literal object."
> Apparently, the intention is instead to indicate that the conceptual
> object called a constant variable (not its value) is not a literal
> object. However, it is unusual for the spec to refer to the concept
> of a variable as an object.
>
> "literal" glossary entry:
>
> (of an object) referenced directly in a program rather than being
> computed by the program; that is, appearing as data in a quote form,
> or, if the object is a self-evaluating object, appearing as unquoted
> data.
>
> This definition does not include references to a value defined by
> DEFCONSTANT.
>
> There is one other source of confusion. Sunil Mishra gives the
> example that some implementations might treat the values of
> DEFCONSTANT as compile-file literals, with references in different
> files being "similar", but not identical. This can lead to confusion.
> The "workaround" is to use DEFPARAMETER instead, which leads to the
> embarrassing situation that a user might tend to think of the value of
> a DEFPARAMETER as more "constant" (really more EQ) across files than
> the value of a DEFCONSTANT. This confusion is furthered, as David
> Lamkins points out, by generally understanding "similar" to mean EQL.
> However, David also points out that the situation only comes up
> through "programmer error" because it violates the original citation
> from 3.2.2.3, above. (Any misinterpretatin of Sunil's and David's
> statements is my fault, not theirs.)
>
> Ultimately, one wonders what is "the right thing." Certainly, one
> want to allow compilers to treat the value of a constant variable as
> some kind of compile-time literal so that partial evaluation can be
> performed at compile time for forms involving references. It comes
> down to a quesion of whether DEFCONSTANT constrains both
> implementations to make sure that the value was similar at all times,
> or just at certain times such as compile and load.
>
> For example, CL already has the issue of what happens when compile
> time and run time definitions differ. Consider an expression like:
> (FOO BAR)
>
> If FOO is an an inlinable reference to the function -, and bar is a
> constant variable with value 1, then the compiler is justified in
> treating the entire expression as the literal value -1. This is true
> even if the user latter arranges for FOO to have a different function
> definition when the above code is actually run. In fact, a different
> reference to (FOO BAR) in a context in which FOO may not be inlined,
> must actually call the run time definition of FOO, and might produce a
> different result.
>
> In other words, we allow the compiler to freeze in the definitions at
> compile time, while still allowing a function binding to change when
> referenced in a different context. In the case of function bindings,
> we're still talking about bindings, not internal structure. (It's
> another can of worms as to whether there should be a way to turn of
> the constantness of a defconstant BINDING.) The question here is
> whether, in the case of DEFCONSTANT, we can allow internal structure
> changes to be picked up at run time.
>
> My own inclination is that we have other mechanisms for disallowing
> changes to internal structure -- namely quoting and load-time-value --
> which could be used in conjunction with the value-form argument to
> DEFCONSTANT if desired. Thus, why force defconstant to be a bigger
> hammer than it needs to be.
>
> In any case, I think it's clear by now
> that any code that relies on an implementation allowing mutations of
> value of defconstant will be non-portable, at minimum.
In article <···············@intellimarket.com>,
Kelly Murray <···@IntelliMarket.Com> writes:
> In my opinion, a Defconstant value should be immutable,
> so it can be placed in a read-only area, and thus can
> be shareable by multiple lisp images.
> What gain is there to allow mutability over a Defvar?
Well, the theory was that a DEFCONSTANT would name a single object and that
that binding couldn't be changed. With a DEFVAR, one set and bind the
variable, which you can't do with a DEFCONSTANT. But given that you can get
non EQ values from the "constant", DEFCONSTANT seems pretty useless to me.
One of the most common uses of DEFCONSTANT (which is in error) was to do
something like what the original poster tried to do. Namely
(defconstant +EOF-VALUE+ (gensym))
for which there's a chance that it won't do what is intended. DEFVAR and
DEFPARAMETER work but don't convey the idea that the binding should be
constant.
> Is their some particular problem with having a DefGlobal
> which declares a variable global?
>
> -Kelly Murray
Kind of depends on what the properties of this proposed DEFGLOBAL are.
Mike McDonald
·······@mikemac.com
From: Kelly Murray
Subject: Re: `fast' global variables (Ex: Re: ??: using * for variable ?)
Date:
Message-ID: <36F824CA.6510D242@IntelliMarket.Com>
Mike McDonald wrote:
>
> In article <···············@intellimarket.com>,
> Kelly Murray <···@IntelliMarket.Com> writes:
> > In my opinion, a Defconstant value should be immutable,
> > so it can be placed in a read-only area, and thus can
> > be shareable by multiple lisp images.
> > What gain is there to allow mutability over a Defvar?
>
> Well, the theory was that a DEFCONSTANT would name a single object and that
> that binding couldn't be changed. With a DEFVAR, one set and bind the
> variable, which you can't do with a DEFCONSTANT. But given that you can get
> non EQ values from the "constant", DEFCONSTANT seems pretty useless to me.
> One of the most common uses of DEFCONSTANT (which is in error) was to do
> something like what the original poster tried to do. Namely
>
> (defconstant +EOF-VALUE+ (gensym))
The most common and very useful purpose of defconstant is
to declare numeric constants, so the compiler can optimize
numerican expressions.
If one can also use it to specify large read-only structures,
so much the better, as there isn't a way to really specify this
property except consing up a quoted expression at compile
time using a macro, as I did in the "reverse-bits" example
a while back.
>
> for which there's a chance that it won't do what is intended. DEFVAR and
> DEFPARAMETER work but don't convey the idea that the binding should be
> constant.
>
> > Is their some particular problem with having a DefGlobal
> > which declares a variable global?
> >
> > -Kelly Murray
>
> Kind of depends on what the properties of this proposed DEFGLOBAL are.
Declaring a variable global to avoid a special-bindings lookup,
which I thoughts was the point of the thread giving the
Subject: of "fast" global variables.
Some get concerned that what is needed is really a "top level lexical"
variable for which no symbol is really needed, i.e. you can't get the
value via #'symbol-value, and this spills over into
defconstant, which has license to elimnate the variable lookup.
-Kelly Murray
From: Kent M Pitman
Subject: Re: `fast' global variables (Ex: Re: ??: using * for variable ?)
Date:
Message-ID: <sfwww07389e.fsf@world.std.com>
Mike McDonald wrote:
> (defconstant +EOF-VALUE+ (gensym))
Incidentally, I usually avoid this for reasons other than those discussed.
The purpose of having a unique value is to assure you never see it as
a result of READ. But if you have it in this variable, then
#.+EOF-VALUE+
will give a bogus eof result when doing READ, and so you defeat the
purpose. I prefer to make a new EOF value lexically in the scope
of whatever routine I'm using just to make sure no program gets to the
eof value. Seems obscure, but I worry about such things.
Btw, to avoid consing, the unique value I almost always use is the stream
itself, which is invariably not found in the stream. As long as it's
not bound to a special (like *standard-input*) it's not available to
the stream. Sometimes I do
(let ((eof stream)) ...)
so that I can still use a variable named EOF instead of the STREAM variable.
Feels kind of weird either way. But it's very practical.
From: Howard R. Stearns
Subject: Re: `fast' global variables (Ex: Re: ??: using * for variable ?)
Date:
Message-ID: <36F8198E.92B23BF9@elwood.com>
Kelly Murray wrote:
>
> In my opinion, a Defconstant value should be immutable,
> so it can be placed in a read-only area, and thus can
> be shareable by multiple lisp images.
> What gain is there to allow mutability over a Defvar?
>
> Is their some particular problem with having a DefGlobal
> which declares a variable global?
>
> -Kelly Murray
Well, another in my series of half-baked new compiler ideas is that
compilation-units/environments and declarations are the proper way to
specify modularity of bindings -- orthogonal to issues of compile-file
literals.
For example, consider that bindings (either function or variable, or
perhaps even other named bindings such as types/classes) can have
declarations indicating to the compiler:
- that the value of the binding, if known, can be used by the compiler
for partial evaluation/inlining
- that the binding can or cannot be considered by the compiler to be
bound at run
time, effecting whether or not boundp/fboundp checks are needed.
- that the value of a binding can be locked in a "load" time - the
compiler can't inline it, but it it can at least arrange to grab its
value at load time (as
though through a (load-time-value ...) and then always use a fast
reference to
that. (This is more or less a "top-level" lexical variable with the
file
scope.)
etc.
Each of these declarations can apply to lexical and global variable, but
of course, the valid values for some of these are more limited for
lexical variables (e.g., a lexical variable cannot ever be unbound).
Thus, in general, the declarations can be introduced over a lexical
scope in the usual way, and global scopes can be effected by
compilation-unit.
If some set of declarations, or programmer action such as quoting,
indicates that a literal can be used at some level (file, module, local
scope, etc.) then so be it.
Defxxx are each understood in terms of these declarations.
Although the idea is to provide both coarse and fine-grained control
over compiler optimizations, I find this model easier to understand than
the specific top level defxxx thingies, and I'm essentially trying to
build concensus for whatever the least restrictive definition of
defconstant can be, so that I can figure out how to implement it in
terms of declarations and environments.
(No, I don't have a specific proposal or any documentation on what these
declarations would cover, nor am I even sure that I understand the
consequences in my own head...)
From: Kent M Pitman
Subject: Re: `fast' global variables (Ex: Re: ??: using * for variable ?)
Date:
Message-ID: <sfwzp53393p.fsf@world.std.com>
Kelly Murray <···@IntelliMarket.Com> writes:
>
> In my opinion, a Defconstant value should be immutable,
> so it can be placed in a read-only area, and thus can
> be shareable by multiple lisp images.
> What gain is there to allow mutability over a Defvar?
See my post earlier this evening for an explanation.
There is a purpose. It doesn't mean you have that purpose.
But some people do, or did--at least until LOAD-TIME-VALUE
came along. LOAD-TIME-VALUE with a NIL second argument is a
very critical need.
> Is their some particular problem with having a DefGlobal
> which declares a variable global?
Political.
There was an issue (PROCLAIM-LEXICAL) which failed and hence was
not recorded in the HyperSpec (mainly because I worried someone would
get confused into thinking it had passed; I suppose I could have found
a way to make it clear it hadn't).
In discussion of PROCLAIM-LEXICAL, which proposed global lexicals, it
became clear that people were of conflicted minds about whether a global
lexical and a global special should have the same value cell, and so
it wasn't clear how many kinds of global were needed.
Jonathan Rees wrote up the issue nicely and in a way that accomodated
the Scheme community's needs. Then it got amended horribly in meetings
to the point where neither the Scheme community could use it nor did
anyone in the CL community want it, but it was not unacceptable to
people (who were ready to vote yes on it because they had defeated the
ill consequences of others' needs, and they (wrongly) still assumed it
had some value to those others). In the end, we almost voted in
something no one wanted but everyone was willing to tolerate, but I
recall polling the room and asking if anyone was still really
*wanting* it and no one said yes. Various people had wanted
something, but it wasn't it. And no one wanted to start over. So we
did nothing.
The issue writeup might be at parcftp.xerox.com somewhere in pub/cl
If not, and if someone really cares, they can ask me and I'll dredge
up the issue and put it somewhere.
From: Vassil Nikolov
Subject: what is DEFCONSTANT (Ex: Re: `fast' global variables #)
Date:
Message-ID: <7d9h2n$131$1@nnrp1.dejanews.com>
Let me try to add a few pieces to the puzzle.
In article <·················@elwood.com>,
"Howard R. Stearns" <······@elwood.com> wrote:
(...)
> Two sections indicate that they are to be immutable:
>
> 3.2.2.3 Semantic Constraints:
(...)
> "constant object" glossary entry
(...)
> Unfortunately, DEFCONSTANT has no direct references to either of these
> entries.
But perhaps an indirect reference would do?
(A) About the middle of the `Macro DEFCONSTANT' section we have
If a defconstant form appears as a top level form, the compiler must
recognize that name names a constant variable.
(B) In `See also' there is a reference to 3.2 and if it is followed,
and then 3.2.2 followed, we come to 3.2.2.3 which talks about constant
variables.
To me, this is quite satisfactory.
> Furthermore, some sections suggest suggest though ommision that the
> value of a constant variable is not a constant object or constant
> literal, and these sections should probably be ammended:
>
> DEFCONSTANT dictionary entry:
>
> The entry explains in detail the constraints on changing the values of
> the constant variable produced by defconstant, when the value might be
> computed, and discusses how the variable may not be bound. However,
> it never says anything about the value being treated as a literal
> object, or about references to internal structures of these values.
Maybe it would have been nice if it was explicit, or the reference
to the other part of the spec more explicit, but there is a reference.
> 3.1.2.1.1.3 Constant Variables:
(...)
> Note that nothing is said about immutability, nor is there any
> reference to constant objects or literal objects.
The reference is elsewhere.
(...) ;I guess I can safely skip these
> 3.2.1 Compiler Terminology:
>
> The term literal object refers to a quoted object or a
> self-evaluating object or an object that is a substructure of such
> an object. A constant variable is not itself a literal object.
>
> Because this specifically refers to constant variables, but only in
> the negative, this could easily be read as indicating that "the value
> of a reference to a constant variable is not itself a literal object."
Well, it is true that every formulation can easily be understood in
the wrong way.
> Apparently, the intention is instead to indicate that the conceptual
> object called a constant variable (not its value) is not a literal
> object. However, it is unusual for the spec to refer to the concept
> of a variable as an object.
I don't think that we have a reference of this kind here. I interpret
A constant variable is not itself a literal object.
as
An entity which is a constant variable is not an entity which is a
literal object.
though this is nit-picking (if that's the word).
> "literal" glossary entry:
(...)
> This definition does not include references to a value defined by
> DEFCONSTANT.
It shouldn't because a constant variable is not a literal object;
a _reference_ to it is equivalent to a _reference_ to a literal
object.
After all, when one sees ``PI,'' one doesn't literally---immediately---
see that the value is a number somewhere between 3 and 4.
(This is one thing that Pascal helped me to learn. With
const three=3;
both THREE and 3 are constants but only the latter is literal.)
> There is one other source of confusion. Sunil Mishra gives the
> example that some implementations might treat the values of
> DEFCONSTANT as compile-file literals, with references in different
> files being "similar", but not identical. This can lead to confusion.
I don't claim that `similar' is easy to understand, but it is defined
comprehensively. Can anyone say specifically what is wrong with this
concept?
(...)
> Ultimately, one wonders what is "the right thing." Certainly, one
> want to allow compilers to treat the value of a constant variable as
> some kind of compile-time literal so that partial evaluation can be
> performed at compile time for forms involving references. It comes
> down to a quesion of whether DEFCONSTANT constrains both
> implementations to make sure that the value was similar at all times,
> or just at certain times such as compile and load.
(...)
I.e., what should DEFCONSTANT be?
When it comes to the notion of defining constants, there are (at least)
two different possibilities:
(1) constant binding to an immutable object.
Offered by DEFCONSTANT as it is now in ANSI Common Lisp.
The good thing about arbitrary forms like calls to MAKE-ARRAY,
and not just literal objects, being allowed as init values
is that sometimes one wants to construct an immutable value
at compile time, not at program writing time.
The other obvious advantage is that the compiler can optimise
for speed and against space by `literalising' the value into
the code.
(2) constant binding to a mutable object.
Nothing in ANSI Common Lisp provides just that.
(This could be used to provide a variable accessible in O(1)
at the expense of not being bindable (my idee fixe again).
I have an idea how this could be implemented reasonably
efficiently and I'll post it RSN.)
It would probably be a good thing to have this in the
language as many people seem to want it. (Not my
implementation but the notion of (2).)
Not that explaining Lisp in terms of C is a good idea (send flames
to me by e-mail so I could post a summary to the group), but C
provides the following bases for analogy:
const int const *cicp; /*like DEFCONSTANT */
int const *icp; /*always the same cell, */
/* but maybe a different value--- */
/* apparently wanted */
const int *cip; /*that would be a variable that must */
/* always be bound to literal objects */
/* ---anybody ever wanted one? */
int const *icp; /*like an unbindable variable, my */
/* fixation */
Vassil Nikolov <········@poboxes.com> www.poboxes.com/vnikolov
(You may want to cc your posting to me if I _have_ to see it.)
LEGEMANVALEMFVTVTVM (Ancient Roman programmers' adage.)
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Vassil Nikolov <········@poboxes.com> writes:
> Not that explaining Lisp in terms of C is a good idea (send flames
> to me by e-mail so I could post a summary to the group), but C
> provides the following bases for analogy:
Nothing like keeping an open mind :-)
> const int const *cicp; /*like DEFCONSTANT */
> int const *icp; /*always the same cell, */
> /* but maybe a different value--- */
> /* apparently wanted */
> const int *cip; /*that would be a variable that must */
> /* always be bound to literal objects */
> /* ---anybody ever wanted one? */
> int const *icp; /*like an unbindable variable, my */
> /* fixation */
I'm confused by your second and fourth forms. They look the same to me. Am
I missing something?
Sunil
From: Vassil Nikolov
Subject: Re: what is DEFCONSTANT (Ex: Re: `fast' global variables #)
Date:
Message-ID: <7dcg10$ivn$1@nnrp1.dejanews.com>
In article <···············@cleon.cc.gatech.edu>,
Sunil Mishra <·······@cleon.cc.gatech.edu> wrote:
(...)
> > const int const *cicp; /*like DEFCONSTANT */
> > int const *icp; /*always the same cell, */
> > /* but maybe a different value--- */
> > /* apparently wanted */
> > const int *cip; /*that would be a variable that must */
> > /* always be bound to literal objects */
> > /* ---anybody ever wanted one? */
> > int const *icp; /*like an unbindable variable, my */
> > /* fixation */
>
> I'm confused by your second and fourth forms. They look the same to me. Am
> I missing something?
(Well, note the last word of the excerpt from me...)
I'm sorry, that was my mistake to repeat the same case twice, with
different comments. I was thinking that there would be 4 cases in all,
but ``int *ip'' is not very relevant, so I came up with the other one
again (subconsciously---I guess I should talk to Eliza about my mother...).
I should have noted instead what I see only now: that two different
concept in Lisp:
- a quasi-defconstant that has a mutable object as its value;
- an unbindable variable;
(one way to see the difference between them is that the latter is setqable,
the former isn't)
both map to the same thing in that trivial C-Lisp analogy. Perhaps
it could become more interesting with C++ which has also ``int &ir''
---but does it have ``int const &icr''?
Vassil Nikolov <········@poboxes.com> www.poboxes.com/vnikolov
(You may want to cc your posting to me if I _have_ to see it.)
LEGEMANVALEMFVTVTVM (Ancient Roman programmers' adage.)
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
In article <············@nnrp1.dejanews.com>,
Vassil Nikolov <········@poboxes.com> writes:
> Let me try to add a few pieces to the puzzle.
>
> In article <·················@elwood.com>,
> "Howard R. Stearns" <······@elwood.com> wrote:
> (...)
>> Two sections indicate that they are to be immutable:
>>
>> 3.2.2.3 Semantic Constraints:
> (...)
>> "constant object" glossary entry
> (...)
>> Unfortunately, DEFCONSTANT has no direct references to either of these
>> entries.
>
> But perhaps an indirect reference would do?
>
> (A) About the middle of the `Macro DEFCONSTANT' section we have
>
> If a defconstant form appears as a top level form, the compiler must
> recognize that name names a constant variable.
>
> (B) In `See also' there is a reference to 3.2 and if it is followed,
> and then 3.2.2 followed, we come to 3.2.2.3 which talks about constant
> variables.
>
> To me, this is quite satisfactory.
In this particular case, I believe the definition of a "constant variable"
that pertains is "a named constant", whose definition is:
named constant n. a variable that is defined by Common Lisp, by the implementation, or by user
code (see the macro defconstant) to always yield the same value when evaluated. ``The value of
a named constant may not be changed by assignment or by binding.''
To me, the important part of this is "to yield the same value when
evaluated".
But I'll concede that the spec is confused and inconsistant enough that just
about any interpretation is possible, rendering DEFCONSTANT pretty close to
useless. The fact that in one place, similar is used instead of same means
that you can't use EQ/EQL when testing against the constant, which breaks most
of the code that I've seen use DEFCONSTANT.
Now I have to go back a figure out what to do about my CLIM implementation.
Its spec requires some CLOS instances to be the value of a constant variable,
typically to be used in generic functions using the eql specifier. But since
EQL doesn't work on "similar", I don't know what to do about them. How does
one test for similarity?
Mike McDonald
·······@mikemac.com
From: Kent M Pitman
Subject: Re: what is DEFCONSTANT (Ex: Re: `fast' global variables #)
Date:
Message-ID: <sfwu2varico.fsf@world.std.com>
·······@mikemac.com (Mike McDonald) writes:
> But I'll concede that the spec is confused and inconsistant enough that just
> about any interpretation is possible, rendering DEFCONSTANT pretty close to
> useless.
This is one of the few "obviously wrong" statements in this whole discussion.
All it means is that a certain set of possible uses of DEFCONSTANT is ruled
out. It doesn't mean that DEFCONSTANT is useless. There is a set of
well-understood uses that are not problematic.
More clarification would broaden its scope of usefulness. The present
situation plainly calls for more "defensive programming style" than
one might wish for.
> Its spec requires some CLOS instances to be the value of a constant variable,
> typically to be used in generic functions using the eql specifier. But since
> EQL doesn't work on "similar", I don't know what to do about them. How does
> one test for similarity?
Conceptually, similar exists to implement EQL across address spaces.
You cannot test for it because it is "defined".
How can two packages in two different lisp images be EQL? They aren't
pointer-equivalent. But they can be similar because the definition of
similarity is not pointer-based.
Although not defined this way, I think of EQL and "similar" as
denoting the same concept but simply implemented differently. I
consider anyone writing a make-load-form that does not yield an EQL
object when the form is loaded into the originating environment as
having made an error (perhaps except where the semantics of the object
is such that it can be proven it will never have EQL called on it--small
amount of wiggle room there).
In article <···············@world.std.com>,
Kent M Pitman <······@world.std.com> writes:
> ·······@mikemac.com (Mike McDonald) writes:
>
>> But I'll concede that the spec is confused and inconsistant enough that just
>> about any interpretation is possible, rendering DEFCONSTANT pretty close to
>> useless.
>
> This is one of the few "obviously wrong" statements in this whole discussion.
> All it means is that a certain set of possible uses of DEFCONSTANT is ruled
> out. It doesn't mean that DEFCONSTANT is useless. There is a set of
> well-understood uses that are not problematic.
Because the ANSI spec allows
(eq +foo+ (some-function-that-always-returns-+foo+))
to return NIL, most common uses of defconstant are now wrong. To me, that
make the ANSI defconstant pretty useless. Granted, if you're not using the
constant for identity but only for effect, then it has some use for read-only
lookup tables.
Mike McDonald
·······@mikemac.com
From: Bill Newman
Subject: Re: what is DEFCONSTANT (Ex: Re: `fast' global variables #)
Date:
Message-ID: <wnewmanF94ICB.Mz0@netcom.com>
Mike McDonald (·······@mikemac.com) wrote:
: In article <···············@world.std.com>,
: Kent M Pitman <······@world.std.com> writes:
: > ·······@mikemac.com (Mike McDonald) writes:
: >
: >> But I'll concede that the spec is confused and inconsistant enough that just
: >> about any interpretation is possible, rendering DEFCONSTANT pretty close to
: >> useless.
: >
: > This is one of the few "obviously wrong" statements in this whole discussion.
: > All it means is that a certain set of possible uses of DEFCONSTANT is ruled
: > out. It doesn't mean that DEFCONSTANT is useless. There is a set of
: > well-understood uses that are not problematic.
: Because the ANSI spec allows
: (eq +foo+ (some-function-that-always-returns-+foo+))
: to return NIL, most common uses of defconstant are now wrong. To me, that
: make the ANSI defconstant pretty useless. Granted, if you're not using the
: constant for identity but only for effect, then it has some use for read-only
: lookup tables.
"pretty close to useless"? with no qualifiers?
Perhaps you mean "pretty close to useless for objects which nontrivial
identity issues," or "pretty close to useless for compound objects" --
the cases we're all arguing about. But DEFCONSTANT is at least useful
for objects where EQL is what we need:
(DEFCONSTANT +MAX-BYTES-PER-INSTRUCTION+ 6)
(DEFCONSTANT +MOST-POSITIVE-ASCII-CHAR-CODE+ 127)
Bill Newman
·······@netcom.com
From: Howard R. Stearns
Subject: Re: what is DEFCONSTANT (Ex: Re: `fast' global variables #)
Date:
Message-ID: <36F90C12.E7349619@elwood.com>
Mike McDonald wrote:
>
> Now I have to go back a figure out what to do about my CLIM implementation.
> Its spec requires some CLOS instances to be the value of a constant variable,
> typically to be used in generic functions using the eql specifier. But since
> EQL doesn't work on "similar", I don't know what to do about them. How does
> one test for similarity?
At first I thought that was a damn good example.
If I understand correctly, CLIM has things like:
+gadget-view+ [Constant]
..an object of class gadget-view.
How can this possibly be implmented such that (constantp '+gadget-view+)
and
(setq x +gadget-view+) ;in one file, and
(setq y +gadget-view+) ;in another, and
(eq x y) ;anywhere
Kent gave the answer. There must be a make-load-form defined for
gadget-view that interns the object.
Now, if it turns out that interning literal gadget-views is wrong headed
for some reason and should not be tolerated, then either CLIM or the
ANSI spec has to give, it seems to me.
In article <·················@elwood.com>,
"Howard R. Stearns" <······@elwood.com> writes:
> Mike McDonald wrote:
>>
>> Now I have to go back a figure out what to do about my CLIM implementation.
>> Its spec requires some CLOS instances to be the value of a constant variable,
>> typically to be used in generic functions using the eql specifier. But since
>> EQL doesn't work on "similar", I don't know what to do about them. How does
>> one test for similarity?
>
> At first I thought that was a damn good example.
>
> If I understand correctly, CLIM has things like:
> +gadget-view+ [Constant]
The example I was thinking of was
(defconstant +nowhere+ (make-instance 'region))
(defconstant +everywhere+ (make-instance 'region))
> Kent gave the answer. There must be a make-load-form defined for
> gadget-view that interns the object.
Now for make-load-form to work in this case, I first have to define the
classes nowhere-region and everywhere-region so that I can write\
(defvar *nowhere-proto* nil)
(defclass nowhere-region (region)
())
(defmethod make-load-form ((x 'nowhere-region) &optional environment)
(declare (ignore environment))
`(or *nowhere-proto* (setq *nowhere-proto* (make-instance 'nowhere-region))))
(defconstant +nowhere+ ??????)
What do I set the defconstant to? (make-instance 'nowhere-region) seems like
it might work for loading the compiled file. As long as I don't evaluate the
defconstant form during development, I should be OK.
I sure seems like a lot of work on the user's part to make "constant
variables" be EQ.
> Now, if it turns out that interning literal gadget-views is wrong headed
> for some reason and should not be tolerated, then either CLIM or the
> ANSI spec has to give, it seems to me.
If you interpret "+everywhere+ is the region" to mean +everywhere+ can be an
instance of a subclass of REGION, then with the make-load-form hack, I should
be able to make it work. Arghh!!
Mike McDonald
·······@mikemac.com
·······@mikemac.com (Mike McDonald) writes:
> The example I was thinking of was
>
> (defconstant +nowhere+ (make-instance 'region))
> (defconstant +everywhere+ (make-instance 'region))
>
> Now for make-load-form to work in this case, I first have to define the
> classes nowhere-region and everywhere-region so that I can write\
>
> (defvar *nowhere-proto* nil)
>
> (defclass nowhere-region (region)
> ())
>
> (defmethod make-load-form ((x 'nowhere-region) &optional environment)
> (declare (ignore environment))
> `(or *nowhere-proto* (setq *nowhere-proto* (make-instance 'nowhere-region))))
>
> (defconstant +nowhere+ ??????)
>
> What do I set the defconstant to? (make-instance 'nowhere-region) seems like
> it might work for loading the compiled file. As long as I don't evaluate the
> defconstant form during development, I should be OK.
>
> I sure seems like a lot of work on the user's part to make "constant
> variables" be EQ.
>
I've also once started implementing something like this. My solution was
(defclass nowhere-class (region) ())
(defvar *nowhere* (allocate-instance (find-class 'nowhere-class)))
(defmethod make-instance ((nowhere nowhere-class) &rest rest)
(declare (ignore rest))
*nowhere*)
(defconstant +nowhere+ (make-instance 'nowhere-class))
But I'm sure it has its own problems I don't quite get yet ;-)
--
Lieven Marchand <···@bewoner.dma.be>
If there are aliens, they play Go. -- Lasker
From: Kent M Pitman
Subject: Re: what is DEFCONSTANT (Ex: Re: `fast' global variables #)
Date:
Message-ID: <sfwww06nvvh.fsf@world.std.com>
·······@mikemac.com (Mike McDonald) writes:
> The example I was thinking of was
> (defconstant +nowhere+ (make-instance 'region))
> (defconstant +everywhere+ (make-instance 'region))
[...]
> Now for make-load-form to work in this case, I first have to define the
> classes nowhere-region and everywhere-region so that I can write\
> (defvar *nowhere-proto* nil)
> (defclass nowhere-region (region) ())
> (defmethod make-load-form ((x 'nowhere-region) &optional environment)
> (declare (ignore environment))
> `(or *nowhere-proto*
> (setq *nowhere-proto* (make-instance 'nowhere-region))))
> (defconstant +nowhere+ ??????)
> What do I set the defconstant to? (make-instance 'nowhere-region) seems like
> it might work for loading the compiled file. As long as I don't evaluate the
> defconstant form during development, I should be OK.
>
> I sure seems like a lot of work on the user's part to make "constant
> variables" be EQ.
7 lines of code? A lot of work? Well, there's no reason you can't make a
metaclass to hide all of this if you really need to. But it's not the
constant variable part that's causing you the work, it's the need to join
up identity across images. And frankly I don't think 7 lines of code is
too much to do that. How do you propose it be done in less?
Saying it'll be EQ doesn't make it so--at least not meaningfully.
If identity matters, it's worth investing in. Identity is about
"caring" about the individuality of instances. Expecting caring to
happen for free is like expecting mass marketing based on information
sharing among mass marketers to magically feel personal one day.
Things don't care about identity unless they have code to do it.
No amount of magic substitutes for that.
Take real cases where identity matters: symbols? the whole baggage of setting
up symbols to really work with naming, interning, etc. is a lot more
investment than what you did above, and it's not done just to make
externalization work--it's needed anyway just to make the symbol data
type meaningful. Packages? Again, their identity matters and when you
save them they have to go to work to make sure they come in on the
other side. That work looks very much like what you wrote above and doesn't
seem excessive to the implementors, I'm sure--they know that "requiring
it to happen by magic" would not improve their chances of having it work
for free. Pathnames? There's one where on the lisp machine pathnames
that are the same are EQ. This is not arranged "by magic" but rather by
very meticulous webs of hash tables that keep everything connected up
in efficient ways. But that cost happens anyway, and incidentally saving
a pathname will get reconstructed as eq later. But in vanilla CL,
pathnames are not interesting for their identity and you also don't have
ways of modifying them. So it doesn't matter if you have the right
one and it isn't the right thing to use EQ. You use EQUAL instead and
this doesn't keep you from using one in defconstant because its identity
doesn't matter.
I just don't see places where this hampers you.
>
> > Now, if it turns out that interning literal gadget-views is wrong headed
> > for some reason and should not be tolerated, then either CLIM or the
> > ANSI spec has to give, it seems to me.
>
> If you interpret "+everywhere+ is the region" to mean +everywhere+ can be an
> instance of a subclass of REGION, then with the make-load-form hack, I should
> be able to make it work. Arghh!!
It's funny but it never occurred to me to compare +everywhere+ by EQ.
I always just assumed it was recognized because it had a certain value
for lo and hi extent along x/y axes. You may think it's faster to use
it by EQ, but what you trade for that is that it's harder to implement
and you also can't have region mutators that take another object and
extend it to mean the same as +everywhere+ because it won't be eq, and
things that are looking for something that "covers" will not recognize
it becuase they're using the wrong predicate.
What it takes to make an object type work is to define the set of operators
you need and then to implement the relevant level of support. But things
like make-load-form and defconstant are subprimitive to that. They do not
have the ability to make that right because they don't know what your
protocol is. That's something that there's no way to specify in CL.
If you're looking for a pity, it's that the language stops short of
saying what matters, and that the result is that some people think that
what matters are the builtins, as if there was some monotonic inclusion
between "builtins" and "what matters" such that if the "builtins" are not
handled, it follows logically that "what matters" can't be handled either.
I don't see that as true.
Nothing keeps you from shadowing EQL in your own package andmaking it mean
whatever you want it to mean. You have define-symbol-macro, you have
metaclasses, ... all the tools are there. But personally, I don't think
you need any of this because there are ample ways to get work done, and
if 7 lines of code is what the price is of getting the behavior you want,
you're well ahead of C or Java, where it takes about that much code just
to do the type casts needed to call a function with the arguments you
want when those arguments aren't in just the right format... ugh.
In article <···············@world.std.com>,
Kent M Pitman <······@world.std.com> writes:
> ·······@mikemac.com (Mike McDonald) writes:
>
>> The example I was thinking of was
>> (defconstant +nowhere+ (make-instance 'region))
>> (defconstant +everywhere+ (make-instance 'region))
>
> 7 lines of code? A lot of work? Well, there's no reason you can't make a
> metaclass to hide all of this if you really need to. But it's not the
> constant variable part that's causing you the work, it's the need to join
> up identity across images.
Which is what a "constant variable" is suppose to be except that in the name
of optimization, compile-file is allowed to make semi-constant variables
instead. And its a dubious optimization at that. Doesn't it bother you at all
that inorder to insure that a "constant variable" has the same value that you
have to first define a "dynamic variable" first?
> And frankly I don't think 7 lines of code is
> too much to do that. How do you propose it be done in less?
> Saying it'll be EQ doesn't make it so--at least not meaningfully.
I propose, as have others, that it be done by compile-file. And that's
accomplished by removing the exception that allows it to use a "similar" value
instead of the same value. Then when a compiled fileis loaded, references to
the "constant variable" fixed much like references to symbols are now. Heck,
the "linker" could even check that the current value of the "constant
variable" was sufficiently similar to what compile-file encountered during
compilation. "Sufficiently similar" would be a function of whatever
optimizations were invoked.
> If identity matters, it's worth investing in.
Indentity is already defined for defconstant except for the exception for
compile-file which only has to return "similar" objects, whatever "similar"
means.
>> If you interpret "+everywhere+ is the region" to mean +everywhere+ can be an
>> instance of a subclass of REGION, then with the make-load-form hack, I should
>> be able to make it work. Arghh!!
>
> It's funny but it never occurred to me to compare +everywhere+ by EQ.
> I always just assumed it was recognized because it had a certain value
> for lo and hi extent along x/y axes.
You mean like plus and minus infinity? Anything less isn't everywhere. CLIM
specifies that there's a unique +everywhere+, not a everywherep predicate.
> What it takes to make an object type work is to define the set of operators
> you need and then to implement the relevant level of support. But things
> like make-load-form and defconstant are subprimitive to that. They do not
> have the ability to make that right because they don't know what your
> protocol is. That's something that there's no way to specify in CL.
But CL already does for "named constants". "a variable that is defined by
Common Lisp, by the implementation, or by user code (see the macro
defconstant) to always yield the same value". Same: 2) objects
indistinguishable by eql. If the exception for compile-file hadn't been added,
the CL would have specified exactly what we're asking for.
> Nothing keeps you from shadowing EQL in your own package andmaking it mean
> whatever you want it to mean.
Unfortunately in my case, there is. The CLIM spec says exactly what symbols
can be exported and EQL isn't one of them.
> You have define-symbol-macro, you have
> metaclasses, ... all the tools are there. But personally, I don't think
> you need any of this because there are ample ways to get work done, and
> if 7 lines of code is what the price is of getting the behavior you want,
> you're well ahead of C or Java, where it takes about that much code just
> to do the type casts needed to call a function with the arguments you
> want when those arguments aren't in just the right format... ugh.
At the moment, it's 775 times 7 lines, all because of the exception granted
compile-file to break the definition of a "constant variable" aka a "named
constant", aka "the same value".
Mike McDonald
·······@mikemac.com
From: Kent M Pitman
Subject: Re: what is DEFCONSTANT (Ex: Re: `fast' global variables #)
Date:
Message-ID: <sfwlnglev0v.fsf@world.std.com>
·······@mikemac.com (Mike McDonald) writes:
> But CL already does for "named constants". "a variable that is defined by
> Common Lisp, by the implementation, or by user code (see the macro
> defconstant) to always yield the same value". Same: 2) objects
> indistinguishable by eql. If the exception for compile-file hadn't been
> added, the CL would have specified exactly what we're asking for.
I hate to quibble here, but the definition of "named constant" does not use
"<I>same</I>" it uses "same", and there <EM>is</EM> a difference.
English words occur way too much in the ANSI CL spec. I tried (within budget)
to make sure that a large number of uses were in conformance with the
specification's glossary. CLTL contained no such references. The meaning
of italicized terms is "this means one of the meanings in the glossary".
The meaning of roman terms is "this might mean one of the meanings in the
glossary or might mean the meanings in the English language dictionary".
The failure to put things in italic is not a simple failure on my part to
make things look more consistent, it is rather a failure on my part to have
the time to visit each and every occurrence of the word in the book and tell
whether or not it belongs in italic or should be changed to another word.
The ANSI CL spec was not written by starting from scratch and additively
choosing terms that built up naturally in a way that all uses would be
correct. It was written by years of chipping away at CLTL (first by Kathy
Chapman, who did a lot of this, and later by me) and laboriously moving each
sentence to a new location that it "better belonged" and laboriously
reconsidering each phrase that Steele had used and trying to reconcile his
sometimes conflicting presentations in a coherent way where I/we hopefully
never changed a sentence or phrase to say something different than he said
other than by vote. That means sometimes we painstakingly changed the wording
or placement of his text to new wording or placement with the same degree of
ambiguity. It wasn't our job to make up truth, only to document what truth
there was and to raise questions about truth before the committee for
clarification.
Sometimes stuff I/we did introduced new meanings by accident and in
the end the vote taken on the specification as a whole was
well-understood to mean that they were casting in conerete any such
"mistakes of processing" into the meaning of the language even if
unintentional because otherwise you the users would not be empowered
to inspect a static document and know what to infer. (I'm sure Steele
feels the same about CLTL, which we all routinely refer to as if he
meant every line and word in it, even though he had his good days and
his bad days writing, and not ever "mistake" was caught by the
proofreaders.) I often sit back and do anything from laugh, smile,
frown, or cry about the ways people look at what I've done and the
intricacies you guys read into what was done.
But while it's utterly fair of you to try to read things into it that are
really there, whether accidentally or intentionally (since you cannot know),
you should stop short of reading things into it that are not there.
And one thing that is not there is any claim that a word in roman means
for sure what the glossary says.
Roman "same" as in the named constant discussion is not necessarily
italic "same", and in a discussion as intricate as the definition of
this complex matter of contants, you really need to allow the spec to
have this terminological subtlety, however inconvenient becuase in
that subtlety you discover exactly the precision of the language that
the vendors were capable of paying for. It cost just shy of half a
million dollars to produce ANSI CL, and to eliminate even more such
ambiguities would have probably cost again as much, and might have
bankrupted another vendor or two. The same money was probably spent,
and properly so, on bringing you a better compiler or CORBA support or
whatever.
I could have mechanically changed all uses of the glossary words so that the
spec would have consistently used all of them in a certain way, but that
would have created huge errors in meaning and I did not do it. I *did*
mechanically mark up the cleanup issues, but I declined to mark up the
glossary words in the cleanup issues exactly because mechanical markup of
that part was intractible. In that case, I marked up none of it and only
made the code words point to glossary stuff--even then there are some places
errors, but at least that's (hopefully) less confusing.
> > Nothing keeps you from shadowing EQL in your own package andmaking it mean
> > whatever you want it to mean.
>
> Unfortunately in my case, there is. The CLIM spec says exactly what symbols
> can be exported and EQL isn't one of them.
>
> > You have define-symbol-macro, you have
> > metaclasses, ... all the tools are there. But personally, I don't think
> > you need any of this because there are ample ways to get work done, and
> > if 7 lines of code is what the price is of getting the behavior you want,
> > you're well ahead of C or Java, where it takes about that much code just
> > to do the type casts needed to call a function with the arguments you
> > want when those arguments aren't in just the right format... ugh.
>
> At the moment, it's 775 times 7 lines, all because of the exception granted
> compile-file to break the definition of a "constant variable" aka a "named
> constant", aka "the same value".
I hope I've made it clear this is too strong an implication. The
reason I couldn't change the font of that one poor feeble word is much
more complex than you suspect. Many uses of roman could have been changed
to italic mechanically, but not all. And this is one.
In some places, too, and this may or may not have been one, I had
tried to rationalize the wording and had decided English was needed to
bootstrap the italic concept. So even with 100% funding, I needed to
sometimes not use glossary terms. (See the definition of "time" in
the glossary for an example; the use of "time line" here in the
definition of time is circular, but the "time line" metaphor was
intended to emphasize your need to get out an English dictionary. I
could have just said "<I>time</I> n. time" but that would have looked a
little weird. I could have introduced more notation so I would have
been saying "<I>time</I> n. <[<time>]>" where "<[<...>]>" was defined
somewhere to say "refer to Webster's" but it wouldn't have made it any
more formal--it would have just looked more formal. English is not
"standardized" or "formal" and its dictionary definitions are just as
circular, and you need after some point just to give up and say "enough
is enough".
Anyway, please feel free to continue to argue away with citations; just
because I wrote the text in some cases doesn't mean I claim a special
knowledge of what I wrote. I once joked about not having read the standard
myself--it would have cost a lot more for me to have spent time reading
what I wrote, and I relied to some degree on having people read what I
had done for errors--certainly for cold readings, since often I did read
stuff right after a change. You may know better what I wrote than I do.
I only know what I intended to write, or what I vaguely reclal having intended
to write. But at least be aware as you research all of this that there
are some notational definitions and they really mean what they say.
Incidentally, one "minor" difference in CLHS vs the hardcopy standard is
that it uses only one kind of "italic"; there are really two kinds of
italic (slant and true italic) in the hardcopy version. Fortunately
for you, I worked very hard to make sure that there was never a slant word
that didn't have its italic meaning, so the fact that the HyperSpec merges
those two sometimes makes things look more ambiguous but does not (probably)
introduce active inconsistency. You may sometimes see it say
the <I>fixnum</I>
in the spec where it really means
the <PARAMETER>fixnum</PARAMETER>
and other times
the <TYPE>fixnum</TYPE>
but since I tried never to pick parameter names that were a type name
unless that parameter was constrained to be of that type, it didn't matter.
(This was a lucky fact of that some hardcopy readers complained they
couldn't distinguish slant and italic visually anyway, so I was already
accomodating this merge in the hardcopy and saying it was just
"optional extra info to be used if convenient and to be ignored if not".)
To some extent, glossary words are the same way--if you don't notice italic
and you think it's roman, that's fine. But if you can tell what italic
is, you must not assume that something is italic that is not marked as
such.
In article <···············@world.std.com>,
Kent M Pitman <······@world.std.com> writes:
> ·······@mikemac.com (Mike McDonald) writes:
>
>> But CL already does for "named constants". "a variable that is defined by
>> Common Lisp, by the implementation, or by user code (see the macro
>> defconstant) to always yield the same value". Same: 2) objects
>> indistinguishable by eql. If the exception for compile-file hadn't been
>> added, the CL would have specified exactly what we're asking for.
>
> I hate to quibble here, but the definition of "named constant" does not use
> "<I>same</I>" it uses "same", and there <EM>is</EM> a difference.
>
> English words occur way too much in the ANSI CL spec. I tried (within budget)
> to make sure that a large number of uses were in conformance with the
> specification's glossary. CLTL contained no such references. The meaning
> of italicized terms is "this means one of the meanings in the glossary".
> The meaning of roman terms is "this might mean one of the meanings in the
> glossary or might mean the meanings in the English language dictionary".
OK. I have the admin's copy of "The New Merriam-Webster Dictionary", 1989
edition, in front of me.
same: 1) being the one refered to, not different
2) similar
syn: identical, equivilant, equal, tantamount
I take it you're agruing the second definition is the "correct" one to use.
So we'll ignore the definition in the glossary and the primary definition in
the dictionary inorder to use the "similar" meaning for same? This is why I
hate language lawyers, they can always find some definition someplace to
justify doing "the wrong thing".
So, how similar is required? For instance, I could now make the claim that
it's legal for my hypothetical compiler to change all "constant variables"
that have fixnum values into floating point ones, single floats into doubles,
ratios into floats, ... (I'm not saying I'd want to but that I could.)
"Similar" is the loophole that allows the compiler writer to do just about
anything he/she wants with constants.
Mike McDonald
·······@mikemac.com
From: Kent M Pitman
Subject: Re: what is DEFCONSTANT (Ex: Re: `fast' global variables #)
Date:
Message-ID: <sfw677pqamo.fsf@world.std.com>
·······@mikemac.com (Mike McDonald) writes:
> OK. I have the admin's copy of "The New Merriam-Webster Dictionary", 1989
> edition, in front of me.
>
> same: 1) being the one refered to, not different
> 2) similar
> syn: identical, equivilant, equal, tantamount
>
> I take it you're agruing the second definition is the "correct" one to use.
Well, I'm not wedded to the particular wording in the dictionary. If
I had to write the English meaning for this purpose, I'd say:
"sufficiently identical for the given purpose". For example, two
twins might often wear the same shirt, and we don't mean they're
co-occupying the same shirt. You and I might have the same idea about
something, and yet if we described it it would come out different. We
might have the same taste in music, but not like the same specific
songs. We might arrive at the same place at the same time without
occupying the same physical point in space/time. A dollar bill and
four quarters might be the same for some purposes, but not for others.
English is more flexible than programming specs are, and that
difference needs to be understood.
> So we'll ignore the definition in the glossary and the primary definition in
> the dictionary inorder to use the "similar" meaning for same? This is why I
> hate language lawyers, they can always find some definition someplace to
> justify doing "the wrong thing".
It isn't about justifying the wrong thing. It's about understanding
that there was no right thing. In contract law (real law, I mean, not
language lawyering), a contract is not said to exist if there is not a
"meeting of the minds". If you agree to sell me something and I agree
to buy it but we later realize we were talking about two different
things, then no contract can be said to exist. You want this language
spec to operate like a contract, and sometimes it should almost do that,
but I claim a conservative reading assumes no contract exists in any place
that a reasonable person might infer an alternate interpretation, because
you basically can't say that the other guy is wrong if he did something
that was consistent with a possible and reasonable understanding of the spec.
That is the guiding principle we always used with CLTL and we have tried
to use with the ANSI CL spec as well. It's lamentable when there isn't
fine agreement, and we try to get informal consensus about how to move
ahead, but such consensus isn't based in pointless talking about what was
intended if what was intended isn't what you wish was intended. It would
be more worth your time to just forget about what was intended and mount
a case for what should happen and approach this newsgroup and each vendor
with a claim about what would be reasonable. At least, that's my feeling.
> So, how similar is required? For instance, I could now make the claim that
> it's legal for my hypothetical compiler to change all "constant variables"
> that have fixnum values into floating point ones, single floats into doubles,
> ratios into floats, ... (I'm not saying I'd want to but that I could.)
> "Similar" is the loophole that allows the compiler writer to do just about
> anything he/she wants with constants.
You could make this claim, but I'm confident the market would reject
it. When vendors are wiling to put their customer base on the line
and go out on a limb, we generally accept that this is the metric of a
"good faith interpretation". For example, my recollection is that we
had to deal long ago (1986; Monterrey meeting; pre-X3J13) with Gold
Hill asserting what I personally felt was the ridiculous claim that
they didn't have to implement lexical scoping and that an
implementation that had only dynamic variables was a "subset" of the
standard. That didn't sit well with other vendors, but you have to
understand that there is no official arbiter who can stand outside and
say "they're wrong and you're right", so we just had to grin and bear
it for a while. Eventually I think it was the market that
straightened that out.
A more subtle example was when Paul Robertson showed up with Robertson
Common Lisp (which later became the Symbolics CLOE product) which he
had developed in insolation of the other vendors and which had a VERY
odd interpretation of the meaning of DEFVAR. The definition had said
that the initial value was evaluated only if needed, and he'd actually
implemented variables to not take a value until they were evaluated,
and THEN to demand-assign them. Everyone else, perhaps because they
were in touch with each other, had assumed the "if needed" applied
to definition-time, not access-time. But he was right--the wording
was awful in Steele. (I hope I fixed it in the ANSI CL spec; the
wording is different--who knows if it's enough of a change to avoid
wrong interpretations but there have been no subsequent complaints.)
We encourage people who are implementing things and who have questions to
try other vendors and to choose someone else's interpretation so that at
least there is some convergence rather than divergence. But we can't
force that. It is in principle possible to make a lisp that is very
different and stretches the meaning of things, and then to go to j13
meetings and claim your "current practice" has standing that should be
given serious weight. (You can even go to the meetings and claim you
deserve attention even without an implementation, of course, but it's
not as compelling. The j13 charter specifically mentions current
practie as being important--even dominant over "aesthetic considerations".)
The market is capable of sorting out what the language spec does not.
That's why we don't have to specify speed issues, etc. Big, slow
implementation get quickly weeded out--and if not, there is a place
for them. Strange interpretations also get weeded out, presumably,
and if not there is a place for them, too.
In article <···············@world.std.com>,
Kent M Pitman <······@world.std.com> writes:
> ·······@mikemac.com (Mike McDonald) writes:
>
>> The example I was thinking of was
>> (defconstant +nowhere+ (make-instance 'region))
>> (defconstant +everywhere+ (make-instance 'region))
>
> 7 lines of code? A lot of work? Well, there's no reason you can't make a
> metaclass to hide all of this if you really need to. But it's not the
> constant variable part that's causing you the work, it's the need to join
> up identity across images.
Which is what a "constant variable" is suppose to be except that in the name
of optimization, compile-file is allowed to make semi-constant variables
instead. And its a dubious optimization at that. Doesn't it bother you at all
that inorder to insure that a "constant variable" has the same value that you
have to first define a "dynamic variable" first?
> And frankly I don't think 7 lines of code is
> too much to do that. How do you propose it be done in less?
> Saying it'll be EQ doesn't make it so--at least not meaningfully.
I propose, as have others, that it be done by compile-file. And that's
accomplished by removing the exception that allows it to use a "similar" value
instead of the same value. Then when a compiled fileis loaded, references to
the "constant variable" fixed much like references to symbols are now. Heck,
the "linker" could even check that the current value of the "constant
variable" was sufficiently similar to what compile-file encountered during
compilation. "Sufficiently similar" would be a function of whatever
optimizations were invoked.
> If identity matters, it's worth investing in.
Indentity is already defined for defconstant except for the exception for
compile-file which only has to return "similar" objects, whatever "similar"
means.
>> If you interpret "+everywhere+ is the region" to mean +everywhere+ can be an
>> instance of a subclass of REGION, then with the make-load-form hack, I should
>> be able to make it work. Arghh!!
>
> It's funny but it never occurred to me to compare +everywhere+ by EQ.
> I always just assumed it was recognized because it had a certain value
> for lo and hi extent along x/y axes.
You mean like plus and minus infinity? Anything less isn't everywhere. CLIM
specifies that there's a unique +everywhere+, not a everywherep predicate.
> What it takes to make an object type work is to define the set of operators
> you need and then to implement the relevant level of support. But things
> like make-load-form and defconstant are subprimitive to that. They do not
> have the ability to make that right because they don't know what your
> protocol is. That's something that there's no way to specify in CL.
But CL already does for "named constants". "a variable that is defined by
Common Lisp, by the implementation, or by user code (see the macro
defconstant) to always yield the same value". Same: 2) objects
indistinguishable by eql. If the exception for compile-file hadn't been added,
the CL would have specified exactly what we're asking for.
> Nothing keeps you from shadowing EQL in your own package andmaking it mean
> whatever you want it to mean.
Unfortunately in my case, there is. The CLIM spec says exactly what symbols
can be exported and EQL isn't one of them.
> You have define-symbol-macro, you have
> metaclasses, ... all the tools are there. But personally, I don't think
> you need any of this because there are ample ways to get work done, and
> if 7 lines of code is what the price is of getting the behavior you want,
> you're well ahead of C or Java, where it takes about that much code just
> to do the type casts needed to call a function with the arguments you
> want when those arguments aren't in just the right format... ugh.
At the moment, it's 775 times 7 lines, all because of the exception granted
compile-file to break the definition of a "constant variable" aka a "named
constant", aka "the same value".
Mike McDonald
·······@mikemac.com
From: Kent M Pitman
Subject: Re: `fast' global variables (Ex: Re: ??: using * for variable ?)
Date:
Message-ID: <sfwbthkka70.fsf@world.std.com>
Vassil Nikolov <········@poboxes.com> writes:
> Yes, but DEFPARAMETER is no different from DEFVAR with respect to being
> fast or slow in lookup of the variable's value, so DEFPARAMETER was of
> no interest to me for the purpose of this particular (self-imposed)
> exercise.
Perhaps:
(defmacro defvassil (var value-form)
`(define-symbol-macro ,var (load-time-value ,value-form)))
Or, if you prefer:
(defmacro defvassil (var value-form)
`(define-symbol-macro ,var
(load-time-value (find-constant-for-vassil ',var ',value-form))))
(defvar *vassil-constants* (make-hash-table))
(defun find-constant-for-vassil (var value-form)
(multiple-value-bind (constant present-p)
(gethash var *vassil-constants*)
(if present-p
constant
(setf (gethash var *vassil-constants*)
(eval value-form)))))
No, I didn't test this. But you get the idea.
From: Vassil Nikolov
Subject: Re: `fast' global variables (Ex: Re: ??: using * for variable ?)
Date:
Message-ID: <7d98m9$pqh$1@nnrp1.dejanews.com>
In article <···············@world.std.com>,
Kent M Pitman <······@world.std.com> wrote:
> Vassil Nikolov <········@poboxes.com> writes:
>
> > Yes, but DEFPARAMETER is no different from DEFVAR with respect to being
> > fast or slow in lookup of the variable's value, so DEFPARAMETER was of
> > no interest to me for the purpose of this particular (self-imposed)
> > exercise.
>
> Perhaps:
>
> (defmacro defvassil (var value-form)
> `(define-symbol-macro ,var (load-time-value ,value-form)))
>
> Or, if you prefer:
>
> (defmacro defvassil (var value-form)
> `(define-symbol-macro ,var
> (load-time-value (find-constant-for-vassil ',var ',value-form))))
>
> (defvar *vassil-constants* (make-hash-table))
>
> (defun find-constant-for-vassil (var value-form)
> (multiple-value-bind (constant present-p)
> (gethash var *vassil-constants*)
> (if present-p
> constant
> (setf (gethash var *vassil-constants*)
> (eval value-form)))))
>
> No, I didn't test this. But you get the idea.
:-)
I'll post my implementation RSN.
Vassil Nikolov <········@poboxes.com> www.poboxes.com/vnikolov
(You may want to cc your posting to me if I _have_ to see it.)
LEGEMANVALEMFVTVTVM (Ancient Roman programmers' adage.)
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
From: Tim Bradshaw
Subject: Re: `fast' global variables (Ex: Re: ??: using * for variable ?)
Date:
Message-ID: <nkj4snc5zqx.fsf@tfeb.org>
Kent M Pitman <······@world.std.com> writes:
> I think it's immutable. I don't have a cite offhand, but I'll hunt around.
> I think you have to say DEFPARAMETER if you don't want the compiler to
> treat it like a literal constant.
Uck. Is there any good reason for this? It would be really nice to
be able to have things who were constant (so could be wired into code)
but not immutable, without weird tricks.
--tim
Kelly Murray wrote:
...
> The real loser in this deal is truly global variables,
> since you must always waste time scanning the binding stack,
> instead of just going directly to the value cell.
> In my true-multiprocessor TopCL implementation,
> I added (defglobal var val) that told the compiler to
> generate straight value-cell lookups to avoid the problem.
The CMUCL native pthread implementation separates symbol global
values from their dynamic bindings. The threads share the
global value slot, and the dynamic value slot is an indirection
to a thread local dynamic binding which uses shallow binding.
When the symbols are declared as globals the compiler generates
an efficient access to the global value slot. Access to
the dynamic binding value, and their binding and unbinding,
is a little slower as it requires an extra indirection.
Even for a general accesses the compiler generates relatively
fast inline code, and performance will improve with some
further compiler smarts. The compiler should be able
to determine that a access is not a global within the scope
of a binding.
A few new extended declarations are required to achieve the best
performance, to declare a symbol value as specifically a global
or a thread local value - perhaps we could coordinate these
user visible extensions?
Regards
Douglas Crosher
In article <················@burlma1-snr2>,
Barry Margolin <······@bbnplanet.com> writes:
> In article <··············@planet.praeclarus.demon.co.uk>,
> Aaron Crane <···········@pobox.com> wrote:
> >I don't follow this question. My understanding was that shallow binding
> >== lexical scoping, and deep binding == dynamic scoping (or special
> >variables as CL puts it). What additional distinction are you drawing?
>
> No, shallow and deep binding are two ways of implementing dynamic
> bindings. With shallow bindings you save the old value on a stack and
> store into the value cell of the object. With deep bindings the dynamic
> environment is an association list of objects and their bindings, and you
> make a new binding by pushing an entry onto the front of the list.
Ah, thanks for the explanation. So in an implementation that uses deep
binding, the unwinding of a LAMBDA (or LET) that binds N special variables
just pops N bindings from the front of the environment alist; while in one
that uses shallow binding, the old values are restored from values popped
from a global dynamic-binding stack.
Or a slightly different approach to shallow binding would be for the value
cell of every symbol to be treated as a stack. Distributing the stack in
this way would make both dynamic binding and stack unwinding simpler. But
then every symbol would need an extra cell for its stack of saved values (or
the value cell would always need to be a cons); since (presumably) most
symbols aren't used as special variables, this is probably unreasonable in
terms of memory utilisation.
> Are deep bindings every really used in serious implementations? I've
> rarely encountered it, and I tend to think of them more as an issue for
> academic discussion of design techniques. The benefit of deep binding is
> that stack unwinding is cheap, but at the expense of slow dynamic variable
> access, and this seems like a poor tradeoff.
Is stack unwinding really significantly cheaper for deep binding than for
shallow binding? It seems to me that the additional work in shallow binding
is only a couple of memory loads and stores; is this an accurate
characterisation?
Anyway, to return to Vassil's earlier question:
In article <············@nnrp1.dejanews.com>,
Vassil Nikolov <········@poboxes.com> writes:
: In article <··············@planet.praeclarus.demon.co.uk>,
: ···········@pobox.com (Aaron Crane) wrote:
: > And of course, given the meta-circular nature of Lisp, we could easily
: > write DYNAMIC-LET in terms of (SETF (DYNAMIC)) and UNWIND-PROTECT.
:
: (1) Wouldn't this explicitly restrict us to shallow binding?
Suppose that you're using a Lisp where you cannot SETQ or LET special
variables, and where (DYNAMIC name) and (SETF (DYNAMIC name)) do the right
thing, but where DYNAMIC-LET doesn't exist. One possible implementation
would be as follows.
;; For simplicity, each binding must be a two-element list
(defmacro dynamic-let (bindings &body body)
(let ((symbols (mapcar #'car bindings))
(old (gensym))
(values (gensym)))
(labels ((setf-forms (vec-name)
(let ((i -1))
(mapcar #'(lambda (sym)
`(setf (dynamic ,sym)
(svref ,vec-name ,(incf i))))
symbols))))
`(let ((,old (vector ,@(mapcar #'(lambda (sym) `(dynamic ,sym))
symbols)))
(,values (vector ,@(mapcar #'cadr bindings))))
(unwind-protect
(progn
,@(setf-forms 'values)
,@body)
,@(setf-forms 'old))))))
This doesn't seem to correspond exactly to either shallow or deep binding:
there's no explicit stack of old values, and there's no global alist of
dynamic bindings. But consing a vector of the old values at runtime and
then allowing the vector to be GCed when control leaves the DYNAMIC-LET is
equivalent to manipulating a stack of values; since that is the case, this
is presumably a slightly obscure case of shallow binding.
I think your question is probably best answered by saying that if you want
to use deep binding for specials, it has to be built in to the
implementation at a low level -- and this is precisely because for deep
binding, dynamic variable access is more complex than simply looking at the
value cell of the relevant symbol.
--
Aaron Crane <···········@pobox.com> <URL:http://pobox.com/~aaronc/>
** Please send on-topic followups by Usenet, not email **
From: Barry Margolin
Subject: Shallow vs deep binding (was Re: ??: using * for variable ?)
Date:
Message-ID: <mJFI2.20$kM2.911@burlma1-snr2>
In article <··············@planet.praeclarus.demon.co.uk>,
Aaron Crane <···········@pobox.com> wrote:
>Ah, thanks for the explanation. So in an implementation that uses deep
>binding, the unwinding of a LAMBDA (or LET) that binds N special variables
>just pops N bindings from the front of the environment alist; while in one
>that uses shallow binding, the old values are restored from values popped
>from a global dynamic-binding stack.
>
>Or a slightly different approach to shallow binding would be for the value
>cell of every symbol to be treated as a stack. Distributing the stack in
>this way would make both dynamic binding and stack unwinding simpler. But
>then every symbol would need an extra cell for its stack of saved values (or
>the value cell would always need to be a cons); since (presumably) most
>symbols aren't used as special variables, this is probably unreasonable in
>terms of memory utilisation.
Also, you still need someplace in the stack to record which variables were
bound in that stack frame, so you know to pop their value stacks.
>Is stack unwinding really significantly cheaper for deep binding than for
>shallow binding? It seems to me that the additional work in shallow binding
>is only a couple of memory loads and stores; is this an accurate
>characterisation?
In shallow binding, unwinding the stack is O(1) -- the stack frame contains
a reference to the dynamic environment that was in place when the stack
frame was entered. You don't have to pop each element off the environment
individually, you just update the environment pointer in one fell swoop.
With deep binding it's O(n), where n is the number of dynamic variables
that were bound in the frame. And it may take more page faults, since it
has to copy data into the value cell of each of those symbols.
But unless you bind lots of dynamic variables in a frame, the difference is
probably minor. That's why I said that it's probably a poor tradeoff --
dynamic variables are probably accessed far more often than they're unbound
due to stack unwinding, so the system should optimize the accesses. That's
why shallow binding is more common.
Deep binding can also be used for lexical variables in an interpreter. In
this case it makes a bit of sense because it's easy to save the environment
list in lexical closures. As you enter and leave lexical contours you form
a tangled network of environments.
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
From: Duane Rettig
Subject: Re: Shallow vs deep binding (was Re: ??: using * for variable ?)
Date:
Message-ID: <4hfrgaf1l.fsf@beta.franz.com>
Barry Margolin <······@bbnplanet.com> writes:
> >Is stack unwinding really significantly cheaper for deep binding than for
> >shallow binding? It seems to me that the additional work in shallow binding
> >is only a couple of memory loads and stores; is this an accurate
> >characterisation?
>
> In shallow binding, unwinding the stack is O(1) -- the stack frame contains
> a reference to the dynamic environment that was in place when the stack
> frame was entered. You don't have to pop each element off the environment
> individually, you just update the environment pointer in one fell swoop.
>
> With deep binding it's O(n), where n is the number of dynamic variables
> that were bound in the frame. And it may take more page faults, since it
> has to copy data into the value cell of each of those symbols.
I think this may be a simple typo: did you mean to discuss deep binding
in the first paragraph and shallow binding in the second?
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
From: Barry Margolin
Subject: Re: Shallow vs deep binding (was Re: ??: using * for variable ?)
Date:
Message-ID: <roHI2.24$kM2.1067@burlma1-snr2>
In article <·············@beta.franz.com>,
Duane Rettig <·····@franz.com> wrote:
>Barry Margolin <······@bbnplanet.com> writes:
>
>> >Is stack unwinding really significantly cheaper for deep binding than for
>> >shallow binding? It seems to me that the additional work in shallow binding
>> >is only a couple of memory loads and stores; is this an accurate
>> >characterisation?
>>
>> In shallow binding, unwinding the stack is O(1) -- the stack frame contains
>> a reference to the dynamic environment that was in place when the stack
>> frame was entered. You don't have to pop each element off the environment
>> individually, you just update the environment pointer in one fell swoop.
>>
>> With deep binding it's O(n), where n is the number of dynamic variables
>> that were bound in the frame. And it may take more page faults, since it
>> has to copy data into the value cell of each of those symbols.
>
>I think this may be a simple typo: did you mean to discuss deep binding
>in the first paragraph and shallow binding in the second?
Yes.
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
From: Vassil Nikolov
Subject: deep vs. shallow binding (Ex: Re: ??: using * for variable ?)
Date:
Message-ID: <7cvvut$42u$1@nnrp1.dejanews.com>
In article <··············@planet.praeclarus.demon.co.uk>,
···········@pobox.com (Aaron Crane) wrote:
(...)
> Anyway, to return to Vassil's earlier question:
(...)
> Suppose that you're using a Lisp where you cannot SETQ or LET special
> variables, and where (DYNAMIC name) and (SETF (DYNAMIC name)) do the right
> thing, but where DYNAMIC-LET doesn't exist. One possible implementation
> would be as follows.
>
> ;; For simplicity, each binding must be a two-element list
> (defmacro dynamic-let (bindings &body body)
> (let ((symbols (mapcar #'car bindings))
> (old (gensym))
> (values (gensym)))
> (labels ((setf-forms (vec-name)
> (let ((i -1))
> (mapcar #'(lambda (sym)
> `(setf (dynamic ,sym)
> (svref ,vec-name ,(incf i))))
> symbols))))
> `(let ((,old (vector ,@(mapcar #'(lambda (sym) `(dynamic ,sym))
> symbols)))
> (,values (vector ,@(mapcar #'cadr bindings))))
> (unwind-protect
> (progn
> ,@(setf-forms 'values)
> ,@body)
> ,@(setf-forms 'old))))))
>
> This doesn't seem to correspond exactly to either shallow or deep binding:
> there's no explicit stack of old values, and there's no global alist of
> dynamic bindings. But consing a vector of the old values at runtime and
> then allowing the vector to be GCed when control leaves the DYNAMIC-LET is
> equivalent to manipulating a stack of values; since that is the case, this
> is presumably a slightly obscure case of shallow binding.
Yes, I think so too, that this is essentially shallow binding.
Once again, my `litmus test' for shallow/deep binding is whether it would
affect other threads.
> I think your question is probably best answered by saying that if you want
> to use deep binding for specials, it has to be built in to the
> implementation at a low level -- and this is precisely because for deep
> binding, dynamic variable access is more complex than simply looking at the
> value cell of the relevant symbol.
Indeed.
In fact, this realisation cooled my excitement about writing a LETF
macro, which would be something like LET for SETF places---but would
`bind' them only in a shallow way, and have doubtful universal
usefulness. (Would be implemented similarly to the above macro.)
Vassil Nikolov <········@poboxes.com> www.poboxes.com/vnikolov
(You may want to cc your posting to me if I _have_ to see it.)
LEGEMANVALEMFVTVTVM (Ancient Roman programmers' adage.)
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
In article <············@nnrp1.dejanews.com>,
Vassil Nikolov <········@poboxes.com> writes:
> In article <··············@planet.praeclarus.demon.co.uk>,
> ···········@pobox.com (Aaron Crane) wrote:
> > (defmacro dynamic-let (bindings &body body)
<snip>
> > I think your question is probably best answered by saying that if you want
> > to use deep binding for specials, it has to be built in to the
> > implementation at a low level -- and this is precisely because for deep
> > binding, dynamic variable access is more complex than simply looking at the
> > value cell of the relevant symbol.
>
> Indeed. In fact, this realisation cooled my excitement about writing a
> LETF macro,
The pseudo-CL support in Emacs Lisp does actually provide this macro.
C-h f letf RET:
: `letf' is a compiled Lisp macro
: -- loaded from "cl-macs.elc"
: (letf BINDINGS &rest BODY)
:
: (letf ((PLACE VALUE) ...) BODY...): temporarily bind to PLACEs.
: This is the analogue of `let', but with generalized variables (in the
: sense of `setf') for the PLACEs. Each PLACE is set to the corresponding
: VALUE, then the BODY forms are executed. On exit, either normally or
: because of a `throw' or error, the PLACEs are set back to their original
: values. Note that this macro is *not* available in Common Lisp.
: As a special case, if `(PLACE)' is used instead of `(PLACE VALUE)',
: the PLACE is not modified before executing BODY.
> which would be something like LET for SETF places---but would `bind' them
> only in a shallow way, and have doubtful universal usefulness.
I'm not sure how `universally useful' it is. A grep over the Lisp source of
XEmacs 20.4 found only two occurrences. But that said, as long as the
caller understands that it's just a macro for UNWIND-PROTECTing a temporary
replacement value for a place, it seems fairly useful to me.
> (Would be implemented similarly to the above macro.)
By the way, it occurs to me that the macro I suggested needs some work to be
generally useful. As it stands, it doesn't correctly introduce new dynamic
bindings -- it should check whether the binding exists beforehand, and if
not, it should MAKUNBOUND the binding afterwards.
--
Aaron Crane <···········@pobox.com> <URL:http://pobox.com/~aaronc/>
** Please send on-topic followups by Usenet, not email **
In article <················@burlma1-snr2>,
Barry Margolin <······@bbnplanet.com> wrote:
(...)
> Are deep bindings every really used in serious implementations? I've
> rarely encountered it, and I tend to think of them more as an issue for
> academic discussion of design techniques. The benefit of deep binding is
> that stack unwinding is cheap, but at the expense of slow dynamic variable
> access, and this seems like a poor tradeoff.
I think Lucid Common Lisp 3.0 (Sun Common Lisp 3.0) had them (don't know
about newer versions), and it was a pretty serious implementation. Also,
didn't Zeta Lisp with its stack groups implement deep binding?
To me, the benefit of deep binding is that in a multithreading Lisp
every thread's dynamic bindings are its own. But let more knowledgeable
people speak on this issue.
Of course, it is well known that you can't have all three operations---
(1) bind a dynamic variable; (2) lookup/set a dynamic variable; (3) change
the dynamic environment (context switch)---in O(1). I believe support
of multithreading is an important factor as to which tradeoff is to be
preferred.
Vassil Nikolov <········@poboxes.com> www.poboxes.com/vnikolov
(You may want to cc your posting to me if I _have_ to see it.)
LEGEMANVALEMFVTVTVM (Ancient Roman programmers' adage.)
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
* Barry Margolin <······@bbnplanet.com>
| Are deep bindings every really used in serious implementations? I've
| rarely encountered it, and I tend to think of them more as an issue for
| academic discussion of design techniques. The benefit of deep binding is
| that stack unwinding is cheap, but at the expense of slow dynamic
| variable access, and this seems like a poor tradeoff.
there may be a reason to use deep binding in a multiprocessing
environment where you may have to switch contexts very often and this
should be virtually free. switching values of a whole bunch of bindings
in a context switch can get expensive in shallow binding. I don't know
if this would actually hold true in any real system or in any real use,
but it's worth noting that context switching is expensive, and perhaps we
will find the best solutions in unexpected corners of the solution space.
#:Erik
Erik Naggum <····@naggum.no> writes:
> there may be a reason to use deep binding in a multiprocessing
> environment where you may have to switch contexts very often and this
> should be virtually free. switching values of a whole bunch of bindings
> in a context switch can get expensive in shallow binding. I don't know
> if this would actually hold true in any real system or in any real use,
> but it's worth noting that context switching is expensive, and perhaps we
> will find the best solutions in unexpected corners of the solution space.
>
And in a multiprocessing environment that runs on multiple CPUS, where
there is no `context switch' this is even worse.
--tim
In article <··············@planet.praeclarus.demon.co.uk>,
···········@pobox.com (Aaron Crane) wrote:
> In article <············@nnrp1.dejanews.com>,
> Vassil Nikolov <········@poboxes.com> writes:
(...)
> > (2) Would this be the same as writing a DYNAMIC-LET for Common Lisp in
> > terms of SETF of SYMBOL-FUNCTION and UNWIND-PROTECT? (Again shallow
> > binding only.)
>
> Yes, I think so (modulo the shallow-binding thing, and assuming that you
> meant SYMBOL-VALUE rather than SYMBOL-FUNCTION).
(...)
Yes, SYMBOL-VALUE of course. My mistake (was thinking at the same time,
is Linear B a functional language...).
Vassil Nikolov <········@poboxes.com> www.poboxes.com/vnikolov
(You may want to cc your posting to me if I _have_ to see it.)
LEGEMANVALEMFVTVTVM (Ancient Roman programmers' adage.)
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
In article <··········@pravda.cc.gatech.edu>,
·····@cc.gatech.edu (Lyman S. Taylor) wrote:
> In article <············@news.gte.com>,
> Dorai Sitaram <····@bunny.gte.com> wrote:
(...)
> >In Common Lisp, you don't ever want to introduce a
> >nonglobal lexical variable with an identifier that is
! ^^^^^^^
> >also used for a global variable.
>
> "ever" is perhaps too strong. :-)
(...)
If FOO is a global (special) variable, then you cannot have a local
*lexical* variable FOO. (Not ever, unless Common Lisp acquires
a `declare notspecial' capability; this has been discussed in CLL,
more than once, I think.)
When the intent is to introduce a local lexical variable FOO, and
when FOO is a global (special) variable, the absence of surrounding
asterisks makes it too easy to do the wrong thing, namely, to write
a program that binds FOO dynamically, not lexically, without noticing.
This may or may not lead to incorrect behaviour depending on the rest
of the program. It will usually lead to worse performance which may
or may not be noticeable.
In the spirit of defensive---most would call it paranoid---programming
one could use a `compiler assertion' that a variable is not special
by using a dummy SYMBOL-MACROLET (to signal an error if the symbol
names a special variable).
Vassil Nikolov <········@poboxes.com> www.poboxes.com/vnikolov
(You may want to cc your posting to me if I _have_ to see it.)
LEGEMANVALEMFVTVTVM (Ancient Roman programmers' adage.)
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own