Hi,
I'm new to lisp, and trying to learn the language from David Lamkins'
book "Successful Lisp". Upon a comment in the book, I tried the
following:
(defun my-function (var)
(write var))
(my-function 34)
(defconstant var 34)
(my-function 34) ;; any value or variable, or constant, doesn't matter
Now, if my understanding is correct, first call to my-function is OK,
but the second one should fail: Lamkins claims that you cannot use a
symbol defconstant'd in a lambda list, and he doesn't make a
distinction between the cases where the function comes first or
defconstant. In any case second call should fail.
On the other hand, I don't see a consistent behavior in the Lisp
interpreters that I use to learn the language: GCL rejects the second
call, and if you try to define a new function with a lambda list
containing var, it gives an error. On the other hand, in CLISP, if the
function is defined before the constant declaration, it works OK, but
you cannot use it in the lambda list of a new function. Corman Lisp
behaves yet differently, it accepts both cases. And others like ECL,
etc. (all free ones) each behaves on their own way as I see.
My question is: I'm a little confused, which one is the
standard-compliant behavior?
Thank you for any clarification.
Regards,
Nusret
> My question is: I'm a little confused, which one is the
> standard-compliant behavior?
CLTL2 says:
X3J13 voted in ....
to clarify that it is an error to rebind constant symbols as either
lexical or special variables. Consequently, a valid reference to a
symbol declared with defconstant always refers to its global value.
So it seems okay to cause an error in both cases.
This is why one should always give constants special names like the
polular +my-constant+ notation.
········@yahoo.com writes:
> My question is: I'm a little confused, which one is the
> standard-compliant behavior?
They are all standard-compliant, since the standard doesn't specifies
exactly what happens.
The point is that there are interpreters and there are compilers, and
the names of lexical variables can disappear from compiled code.
eg. in clisp:
[152]> (disassemble (compile (defun my-function (var) (write var))))
Disassembly of function MY-FUNCTION
1 required argument
0 optional arguments
No rest parameter
No keyword parameters
4 byte-code instructions:
0 (LOAD&PUSH 1)
1 (PUSH-UNBOUND 17)
3 (CALLS1 130) ; WRITE
5 (SKIP&RET 2)
NIL
See, there's no VAR anymore.
Of course in clisp, if you don't explicitely compile, you get the
interpreter, and with an interpreter you could get the error for
rebinding a constant. clisp is nice in letting you use a function
defined before the constant. Other interpreters are entitled to raise
an error even in this case.
As Benjamin wrote, this is the reason for the +cste+ convention for
constant names.
--
__Pascal Bourguignon__ http://www.informatimago.com/
CAUTION: The mass of this product contains the energy equivalent of
85 million tons of TNT per net ounce of weight.
Pascal Bourguignon wrote:
> They are all standard-compliant, since the standard doesn't specifies
> exactly what happens.
Do other people agree with this statement? So, why does Lamkins write
that you cannot rebind a constant in a let or lambda list? I don't say
what you're saying is wrong, just found it strange that all behaviors
described (even Corman Lisp's) in my post are standard compliant?
Exactly what does the standard state then? Sorry, I don't have a copy
of the standard: just in case someone knows for sure...
I'm not particularly interested in the compiled code at this point
(I've started just a few days ago, and just for fun :): people can do
all sorts of tricks with a compiler. Good to know though, thank you.
Just to learn, not to write such ambiguous and uncertain code..
Regards,
Nusret
"new_to_lisp" <········@yahoo.com> writes:
> Pascal Bourguignon wrote:
>
>> They are all standard-compliant, since the standard doesn't specifies
>> exactly what happens.
>
> Do other people agree with this statement? So, why does Lamkins write
> that you cannot rebind a constant in a let or lambda list? I don't say
> what you're saying is wrong, just found it strange that all behaviors
> described (even Corman Lisp's) in my post are standard compliant?
> Exactly what does the standard state then? Sorry, I don't have a copy
> of the standard: just in case someone knows for sure...
>
> I'm not particularly interested in the compiled code at this point
> (I've started just a few days ago, and just for fun :): people can do
> all sorts of tricks with a compiler. Good to know though, thank you.
>
> Just to learn, not to write such ambiguous and uncertain code..
Lamkins says that if you want to get defined behavior, then you cannot
rebind a constant in a let or lambda list. This is the contraposed of
what the standard specifies [ (p => q) <=> ((not q) => (not p)) ]:
http://www.lispworks.com/documentation/HyperSpec/Body/m_defcon.htm#defconstant
The consequences are undefined if there are any bindings of the
variable named by name at the time defconstant is executed or if
the value is not eql to the value of initial-value.
The consequences are undefined when constant symbols are rebound as
either lexical or dynamic variables. In other words, a reference to
a symbol declared with defconstant always refers to its global
value.
Of course, the last sentence is either false or imprecise: a symbol
is declared with defconstant only when the defconstant form is
executed. Before it is not declared with defconstant (yet). Since you
cannot expect common lisp implementations to know the future, the
symbol cannot always refer to its global value! So it's not always,
it's at most, "always thereafter".
--
__Pascal Bourguignon__ http://www.informatimago.com/
ADVISORY: There is an extremely small but nonzero chance that,
through a process known as "tunneling," this product may
spontaneously disappear from its present location and reappear at
any random place in the universe, including your neighbor's
domicile. The manufacturer will not be responsible for any damages
or inconveniences that may result.
I see your point and that makes sense to me. Probably they mean "after
the constant declaration", but that either breaks the code (as in GCL),
or you have to work around as in the case of CLISP (or completely
ignore this part of the standard, as in Corman Lisp :). Thanks a lot
for your taking time to explain things; I appreciate it.
Regards,
Nusret
In article <······················@u72g2000cwu.googlegroups.com>,
"new_to_lisp" <········@yahoo.com> wrote:
> I see your point and that makes sense to me.
Several people have made different points in this thread. Which one are
you talking about? You need to provide context, most of us aren't using
Google's forum-style interface. Please see
http://cfaj.freeshell.org/google/
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
Barry,
I can't tell you what to use, it's up to you. However,
I explained what I meant. If that's not enough, just move on and ignore
my message.
Regards,
Nusret
From: Jim Smith
Subject: Re: defconstant a symbol already used in a lambda list
Date:
Message-ID: <x6irqhzg8x.fsf@gmail.com>
"new_to_lisp" <········@yahoo.com> writes:
> Barry,
> I can't tell you what to use, it's up to you. However,
> I explained what I meant. If that's not enough, just move on and ignore
> my message.
He is trying to tell you that you need to learn how to post to usenet.
Read the link he provided.
HTH.
To reiterate what Pascal has correctly stated, the standard (as is
true with most language standards) states rules about what constitutes
a correctly formed common lisp program. It leaves to compiler
implemantations to decide what to do with incorrectly written code.
One implemenation might favor tight error checking, and trade
compile-time and run-time performance for better user feedback when
standards are violated. Another implementation might choose to
interpret non-standard code in a predictable way, providing its own
definition for its meaning. I suppose the best way is to provide lots
of feedback about conformance that can be turned off with
declarations.
I will add a check for this to the Corman Lisp compiler--I believe we
should give an error in this case. It was not the intent of the
designer that constants could be rebound and in this case they are--I
consider this a compiler bug.
Roger Corman
---------------------------------------
On 12 Mar 2006 15:23:44 -0800, "new_to_lisp" <········@yahoo.com>
wrote:
>Pascal Bourguignon wrote:
>
>> They are all standard-compliant, since the standard doesn't specifies
>> exactly what happens.
>
>Do other people agree with this statement? So, why does Lamkins write
>that you cannot rebind a constant in a let or lambda list? I don't say
>what you're saying is wrong, just found it strange that all behaviors
>described (even Corman Lisp's) in my post are standard compliant?
>Exactly what does the standard state then? Sorry, I don't have a copy
>of the standard: just in case someone knows for sure...
>
>I'm not particularly interested in the compiled code at this point
>(I've started just a few days ago, and just for fun :): people can do
>all sorts of tricks with a compiler. Good to know though, thank you.
>
>Just to learn, not to write such ambiguous and uncertain code..
>
>Regards,
>
>Nusret