>From page 202 of Touretzky's "Common Lisp: ...Introduction..." book,
there is this passage:
"Note that only oridinay funtions can be quoted with sharp-quote. It
is an error to quote a macro function or special function this way".
Then he gave an example like this:
> #'if
Error: IF is not an ordinary function.
I tried his example on sbcl 0.9.13 but got a different result:
CL-USER>#'if
#<FUNCTION (LAMBDA (&REST REST)) {9AEB6F5}>
I looked up CLHS which has this to say under FUNCTION:
"It is an error to use function on a function name that does not
denote a function in the lexical environment in which the function
form appears. Specifically, it is an error to use function on a symbol
that denotes a macro or special form. An implementation may
choose not to signal this error for performance reasons, but
implementations are forbidden from defining the failure to signal an
error as a useful behavior."
So, is the sbcl implementation of function sharp-quoting wrong in
terms of ANSI conformance?
Doug
doug wrote:
> I looked up CLHS which has this to say under FUNCTION:
> "It is an error to use function on a function name that does not
> denote a function in the lexical environment in which the function
> form appears. Specifically, it is an error to use function on a symbol
> that denotes a macro or special form. An implementation may
> choose not to signal this error for performance reasons, but
> implementations are forbidden from defining the failure to signal an
> error as a useful behavior."
>
> So, is the sbcl implementation of function sharp-quoting wrong in
> terms of ANSI conformance?
No. The ANSI standard is screwing up here. Since the situation is an
error, and an error condition not required, the implementation may do
anything at all: i.e. the consequences are undefined.
The standard cannot mark some behavior undefined, yet forbid useful
extensions there. That's absurd, because it's tantamount to saying that
only bad things can happen, but not any benign or even good things:
that, for instance, it's okay for your hard drive to be reformatted, or
for demons to fly out of your nose, but it's not okay for a function
object to be reliably produced. Huh?
What about these "performance reasons"? What are those? Just about any
implementation decision can be justified using some kind of
"performance reasons", so basically it's up to implementor whim whether
that requirement is implemented. A requirement that is conditional to
implementor whim is as good as no requirement at all: no portable
program can rely on the error being signaled since any implementation
may omit it for its own performance reasons.
What is "useful" behavior is subjective. Is that term even defined in a
glossary? A standard is a contract between the implementor and user. So
it's ultimately up to those parties to decide what is useful.
The right way to specify this would have been to require the error to
be signaled in safe code. That's the right way to make an error check
removable for performance reasons: if the user cares about performance,
he can declare the safety quality to be less than 3, etc. There is a
normative term for this defined in 1.4.2: "An error should be
signaled".
"Kaz Kylheku" <········@gmail.com> writes:
> doug wrote:
> > I looked up CLHS which has this to say under FUNCTION:
> > "It is an error to use function on a function name that does not
> > denote a function in the lexical environment in which the function
> > form appears. Specifically, it is an error to use function on a symbol
> > that denotes a macro or special form. An implementation may
> > choose not to signal this error for performance reasons, but
> > implementations are forbidden from defining the failure to signal an
> > error as a useful behavior."
> >
> > So, is the sbcl implementation of function sharp-quoting wrong in
> > terms of ANSI conformance?
> No. The ANSI standard is screwing up here. Since the situation is an
> error, and an error condition not required, the implementation may do
> anything at all: i.e. the consequences are undefined.
>
> The standard cannot mark some behavior undefined, yet forbid useful
> extensions there. That's absurd, because it's tantamount to saying that
> only bad things can happen, but not any benign or even good things:
> that, for instance, it's okay for your hard drive to be reformatted, or
> for demons to fly out of your nose, but it's not okay for a function
> object to be reliably produced. Huh?
The normative reason (it may even be written down somewhere, perhaps
at least in one of the J13 proposal texts) for prohibitions on global
definitions is this: Suppose Application A defines IF to be one thing,
and Application B defines IF to be somethiong else that is incompatible.
Then if A and B are made to coexist in the same lisp, one definition
will win out (they cannot both be in effect, since (symbol-function 'if)
is a global location) and the other app will die because its definition
of IF is not what it was expecting.
However, in this case we are talking not about an application, but an
implementation. I'm not sure what the reasoning is in this case, since
there is only one implementation and the only problem becomes program
portability (which is already the case for any extension provided by
an implementation).
However, it is also not just an anomaly in the wording for FUNCTION;
Note in 11.1.2.1.1 there are various constraints on the implementation
which back the claim up.
We had similar issues with a few functions whose symbols were in the
CL package - we had giiven definitions (useful, in our opinion) to
DOUBLE-FLOAT, SINGLE-FLOAT, and SIMPLE-STRING, but were convinced by
the texts of the spec to remove them and to place them into other
symbols.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig <·····@franz.com> writes:
> "Kaz Kylheku" <········@gmail.com> writes:
>
>> doug wrote:
>> > So, is the sbcl implementation of function sharp-quoting wrong in
>> > terms of ANSI conformance?
>
>> No. The ANSI standard is screwing up here. Since the situation is an
>> error, and an error condition not required, the implementation may do
>> anything at all: i.e. the consequences are undefined.
>>
>> The standard cannot mark some behavior undefined, yet forbid useful
>> extensions there. That's absurd, because it's tantamount to saying that
>> only bad things can happen, but not any benign or even good things:
>> that, for instance, it's okay for your hard drive to be reformatted, or
>> for demons to fly out of your nose, but it's not okay for a function
>> object to be reliably produced. Huh?
> [...]
> However, in this case we are talking not about an application, but an
> implementation. I'm not sure what the reasoning is in this case, since
> there is only one implementation and the only problem becomes program
> portability (which is already the case for any extension provided by
> an implementation).
>
> However, it is also not just an anomaly in the wording for FUNCTION;
> Note in 11.1.2.1.1 there are various constraints on the implementation
> which back the claim up.
I think it is an anomaly in the wording for FUNCTION, because
FDEFINITION and SYMBOL-FUNCTION on special operators are specified to
return objects of implementation-dependent nature. At least, I think
it's within the spirit of the standard to return the same object for
(function cl:if) as for (symbol-function 'cl:if), as this preserves
the uniformity of the semantics of function binding (since, by the
restrictions on portable programs, an implementation is free to assume
that cl:if has not been bound as a function) while not being a
terribly useful object.
Christophe
Christophe Rhodes <·····@cam.ac.uk> writes:
> Duane Rettig <·····@franz.com> writes:
>
>> "Kaz Kylheku" <········@gmail.com> writes:
>>
>>> doug wrote:
>>> > So, is the sbcl implementation of function sharp-quoting wrong in
>>> > terms of ANSI conformance?
>>
>>> No. The ANSI standard is screwing up here. Since the situation is an
>>> error, and an error condition not required, the implementation may do
>>> anything at all: i.e. the consequences are undefined.
>>>
>>> The standard cannot mark some behavior undefined, yet forbid useful
>>> extensions there. That's absurd, because it's tantamount to saying that
>>> only bad things can happen, but not any benign or even good things:
>>> that, for instance, it's okay for your hard drive to be reformatted, or
>>> for demons to fly out of your nose, but it's not okay for a function
>>> object to be reliably produced. Huh?
>> [...]
>> However, in this case we are talking not about an application, but an
>> implementation. I'm not sure what the reasoning is in this case, since
>> there is only one implementation and the only problem becomes program
>> portability (which is already the case for any extension provided by
>> an implementation).
>>
>> However, it is also not just an anomaly in the wording for FUNCTION;
>> Note in 11.1.2.1.1 there are various constraints on the implementation
>> which back the claim up.
>
> I think it is an anomaly in the wording for FUNCTION, because
> FDEFINITION and SYMBOL-FUNCTION on special operators are specified to
> return objects of implementation-dependent nature. At least, I think
> it's within the spirit of the standard to return the same object for
> (function cl:if) as for (symbol-function 'cl:if), as this preserves
> the uniformity of the semantics of function binding (since, by the
> restrictions on portable programs, an implementation is free to assume
> that cl:if has not been bound as a function) while not being a
> terribly useful object.
But FUNCTION operates on the lexical environment (which may include
the global) whereas SYMBOL-FUNCTION and FDEFINITION operate in the
global environment. If you were to consider a CL name that had not
had any other global binding (e.g. DOUBLE-FLOAT) the global function
definition cannot be defined by the implementation (via 11.1.2.1.1)
and thus any user program can with confidence do the following:
...
(flet ((double-float (...) ...)))
according to 11.1.2.1.2.1. In this case, within the second elipsis
the values returned (if anything) will be different for FUNCTION
(which will return the flet) as for SYMBOL-FUNCTION (which should
signal error).
OK, back to IF. If is already a special-operator, and thus falls under
11.1.2.1.1 - SYMBOL-FUNCTION returns something implementation independent,
and FUNCTION will either return the same thing (considering that the global
definition, being implementation dependent, is in fact a function-like
object), or it will error. The implementation is not allowed to create
lexical functional bindings for IF, per 11.1.2.1.1, and users are not
allowed to put lexical functional bindings on IF per the combination of
the second bullet in 11.1.2.1.2 coupled with the lack of any applicable
exceptions in 11.1.2.1.2.1. As far as I can see, it is pretty tightly
sealed, and the FUNCTION's description does not conflict with this
constraints section. What it is saying is that although the "function
cell" described in SYMBOL-FUNCTION might implement a macro or
special-operator definition, and thus FUNCTION might return an
(implementation-dependent) object, that object had better not be able
to do something useful (e.g. it had better not be funcallable). I think
the reasons for this are similar to the reasoning for not allowing macros
and special-forms to be funcalled in the first place.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig wrote:
> constraints section. What it is saying is that although the "function
> cell" described in SYMBOL-FUNCTION might implement a macro or
> special-operator definition, and thus FUNCTION might return an
> (implementation-dependent) object, that object had better not be able
> to do something useful (e.g. it had better not be funcallable).
For reference, the behaviour SBCL actually implements is:
* (funcall #'if 1 2 3) ; the same happens with SYMBOL-FUNCTION
debugger invoked on a SB-INT:SPECIAL-FORM-FUNCTION:
Cannot FUNCALL the SYMBOL-FUNCTION of special operator IF.
...it just happens that the function object of "implementation defined
nature" happens to be a function whose sole purpose in life is to
signal that error.
Cheers,
-- Nikodemus Siivola
"Nikodemus Siivola" <·········@random-state.net> writes:
> Duane Rettig wrote:
>
>> constraints section. What it is saying is that although the "function
>> cell" described in SYMBOL-FUNCTION might implement a macro or
>> special-operator definition, and thus FUNCTION might return an
>> (implementation-dependent) object, that object had better not be able
>> to do something useful (e.g. it had better not be funcallable).
>
> For reference, the behaviour SBCL actually implements is:
>
> * (funcall #'if 1 2 3) ; the same happens with SYMBOL-FUNCTION
>
> debugger invoked on a SB-INT:SPECIAL-FORM-FUNCTION:
> Cannot FUNCALL the SYMBOL-FUNCTION of special operator IF.
>
> ...it just happens that the function object of "implementation defined
> nature" happens to be a function whose sole purpose in life is to
> signal that error.
As it is in Allegro CL. This is as it should be, and is likely one
of the reasons for the seemingly strange wording in the spec. In
actual implementations, a useful design is to determine that a symbol's
function cell _always_ contains a ***::function-object-p object - this
makes funcall dispatch much more efficient than if funcall had to
determine whether an object (besides nil) was in that slot, and what
type of object was there; how to call it, etc. When a function-like
object can be guaranteed to be within the symbol-function slot, then
it only takes a few instructions to call a symbol - nevermind that the
symbol is inappropriate to call; the start address of that particular
(implementation-dependent-but-looking-remarkably-like-a-function) object
can point to code that calls error. Note in Allegro CL the function slot
of even unbound functions is not nil, but it points to the
unbound-"function" (which then allows the undefined-function error to be
signalled without pessimizing the calls to legitimate functions).
CL-USER(1): 'a
A
CL-USER(2): :i *
A NEW The symbol A @ #x406eb247
which is an INTERNAL symbol in the COMMON-LISP-USER package
0 type ---------> Bit field: #x07
1 flags --------> Bit field: #x00
2 package ------> The COMMON-LISP-USER package
3 value --------> ..unbound..
4 function -----> ..funbound..
5 hash ---------> Bit field: #x6f5750
6 name ---------> A simple-string (1) "A"
7 plist --------> The symbol NIL
CL-USER(3): :i raw
A NEW The symbol A @ #x406eb247
which is an INTERNAL symbol in the COMMON-LISP-USER package
0 type ---------> Bit field: #x07
1 flags --------> Bit field: #x00
2 package ------> fixnum 7 [#x0000001c]
3 value --------> ..unbound..
4 function -----> #<Function (unnamed) @ #x40001782>
5 hash ---------> Bit field: #x6f5750
6 name ---------> A simple-string (1) "A"
7 plist --------> The symbol NIL
CL-USER(4):
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Christophe Rhodes <·····@cam.ac.uk> writes:
> At least, I think
> it's within the spirit of the standard to return the same object for
> (function cl:if) as for (symbol-function 'cl:if), as this preserves
> the uniformity of the semantics of function binding (since, by the
> restrictions on portable programs, an implementation is free to assume
> that cl:if has not been bound as a function) while not being a
> terribly useful object.
I think this is a fallacious argument. What you're saying is that
there's is a domain D of values for which 2 functions return the
same values, and then you choose a distinct domain D' and still want
the functions to return the same values. Why do you have two
functions to start with? Why talk about 2 domains at all?
A similar weak argument that could equally be invoked in the name of
"the spirit of the standard" would be that while (SYMBOL-FUNCTION 'IF)
returns some object not furthermore specified, users clearly do not
want #'IF to work by accident. As FUNCTION is the thing behind #', it
follows that #'IF == (FUNCTION 'IF) ought to signal an error.
I don't buy into this argument more than the other, I just wanted to
point at the rhetoric.
Regards,
Jorg Hohle
Telekom/T-Systems Technology Center
Joerg Hoehle wrote:
> A similar weak argument that could equally be invoked in the name of
> "the spirit of the standard" would be that while (SYMBOL-FUNCTION 'IF)
> returns some object not furthermore specified, users clearly do not
> want #'IF to work by accident. As FUNCTION is the thing behind #', it
> follows that #'IF == (FUNCTION 'IF) ought to signal an error.
>
> I don't buy into this argument more than the other, I just wanted to
> point at the rhetoric.
It does have the point of early failure and easily pinpointed location
in its favor, actually.
Cheers,
-- Nikodemus
On 6 Jun 2006 00:10:02 -0700, "doug" <·········@yahoo.com> tried to
confuse everyone with this message:
>>From page 202 of Touretzky's "Common Lisp: ...Introduction..." book,
>there is this passage:
>"Note that only oridinay funtions can be quoted with sharp-quote. It
>is an error to quote a macro function or special function this way".
>
>Then he gave an example like this:
>> #'if
>Error: IF is not an ordinary function.
>
>I tried his example on sbcl 0.9.13 but got a different result:
>CL-USER>#'if
>#<FUNCTION (LAMBDA (&REST REST)) {9AEB6F5}>
>
You found an uber-secret IF function that SBCL creators added for
misterious purposes. Did you try (funcall #'if ...)?
Note that you can change symbol-function slot of any symbol, for example
in my Lisp #'if gives an error, but after some twiddling...
CL-USER> (setf (symbol-function 'if) (lambda (c y n) (cond ((not c) n)
(t y))))
#<FUNCTION :LAMBDA (C Y N) (COND ((NOT C) N) (T Y))>
CL-USER> #'if
#<FUNCTION :LAMBDA (C Y N) (COND ((NOT C) N) (T Y))>
So now there is a function IF. I wanted to find which IF would be used
by default so I ran this sequence of commands:
CL-USER> (defvar x 1)
X
CL-USER> (if (= x 1) (setf x 2) (setf x 3))
2
CL-USER> x
3
which proves that CLISP uses IF function by default (unlike SBCL). Which
is probably a bug. Despite CL package being locked I managed to
completely redefine IF, making it a function rather than a special
operator. And of course it opens some devilish possibilities...
--
|Don't believe this - you're not worthless ,gr---------.ru
|It's us against millions and we can't take them all... | ue il |
|But we can take them on! | @ma |
| (A Wilhelm Scream - The Rip) |______________|
doug wrote:
>>From page 202 of Touretzky's "Common Lisp: ...Introduction..." book,
> there is this passage:
> "Note that only oridinay funtions can be quoted with sharp-quote. It
> is an error to quote a macro function or special function this way".
>
> Then he gave an example like this:
>> #'if
> Error: IF is not an ordinary function.
>
> I tried his example on sbcl 0.9.13 but got a different result:
> CL-USER>#'if
> #<FUNCTION (LAMBDA (&REST REST)) {9AEB6F5}>
>
> I looked up CLHS which has this to say under FUNCTION:
> "It is an error to use function on a function name that does not
> denote a function in the lexical environment in which the function
> form appears. Specifically, it is an error to use function on a symbol
> that denotes a macro or special form. An implementation may
> choose not to signal this error for performance reasons, but
> implementations are forbidden from defining the failure to signal an
> error as a useful behavior."
>
> So, is the sbcl implementation of function sharp-quoting wrong in
> terms of ANSI conformance?
What does the last sentence of the quoted passage say?
Pascal
--
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
Pascal Costanza wrote:
> doug wrote:
> > choose not to signal this error for performance reasons, but
> > implementations are forbidden from defining the failure to signal an
> > error as a useful behavior."
> >
> > So, is the sbcl implementation of function sharp-quoting wrong in
> > terms of ANSI conformance?
>
> What does the last sentence of the quoted passage say?
The real question is: how would you write a conformance test case that
would distinguish a useful extension from other behavior, thereby
identifying the non-conformance?
If you can't write a program to discover whether a programming language
requirement has been violated, then it's not a real requirement.
:)
From: Kent M Pitman
Subject: Re: sharp-quoting special functions
Date:
Message-ID: <u1wu1vgz2.fsf@nhplace.com>
"Kaz Kylheku" <········@gmail.com> writes:
> Pascal Costanza wrote:
> > doug wrote:
> > > choose not to signal this error for performance reasons, but
> > > implementations are forbidden from defining the failure to signal an
> > > error as a useful behavior."
> > >
> > > So, is the sbcl implementation of function sharp-quoting wrong in
> > > terms of ANSI conformance?
> >
> > What does the last sentence of the quoted passage say?
>
> The real question is: how would you write a conformance test case that
> would distinguish a useful extension from other behavior, thereby
> identifying the non-conformance?
>
> If you can't write a program to discover whether a programming language
> requirement has been violated, then it's not a real requirement.
>
> :)
The language spec is akin to a contract between two parties. It
effectively says what the requirements are on each party. That is, it
says what implementations must do in order to expect to run conforming
programs, and it says what programs must do in order to expect to
behave in a predictable way with a conforming processor.
In effect, although the wording is admittedly odd (sorry about that),
I'd construe this is a requirement on programs, not a requirement on
implementations. That is, it effectively forbids programs from
believing any claim that the behavior is dependable, and consequently
reserves the right to make changes to this area of the language in a
future standard, since by definition no conforming program can be
depending on the matter... not that I'd expect that to happen in the
forseeable future.
What Kaz says about requirements may technically be true, but a lot of
the world relies on people following rules that can't be enforced.
Manners are effectively that: a soft requirement that keeps people
from getting close enough to the edge of what's really allowed that
people feel the need to move the edge.
While there may be reasons to violate manners, and while it's
certainly true that manners cannot in general be enforced, it's unwise
to claim that a logical consequence of this is that manners don't
matter. If people don't stop at manners, they will push to the edge
of law. And if they do that, enough people will feel uncomfortable
and will change the law, usually making it more restrictive in order
to keep the bad guys out, but at the same time keeping innocent uses
out. (Whatever one thinks of the DMCA, and I'm no fan of it, it seems
plausible to assume it's an effect such as what I'm describing.)
Following on a similar line of thinking, while it's strictly true that
"if you can't write a program to discover whether a programming
language requirement has been violated, then it's not a real
requirement", it's also true (read: HP Grice on Conversational
Implicature, referenced in others of my posts) that there's no point
in making statements that have no meaning, so this statement can
realistically only be interpreted as being offered for its truth
value. e.g., it appears on its face, following Grice's rules, to give
a subtext of permission/approval. You may construe my remarks here
as giving a balancing subtext of lack of permission and disapproval. ;)
Programming style may not be enforceable, but I have found in my career
that people crave it, and that a certain limited amount of it even in
a spec goes a long way. The remarks about the grammatical form of an
error message are similarly unenforceable, as are the things about *'s
around a special variable name. But they're still useful and I recommend
that people don't take "lack of enforceability" as permission.
Dick Gabriel used to conceptually hang over my shoulder (he was far
away mostly, so tended to do this remotely) when I was writing the
spec and line out things where I'd say "should" because he had some
transformation that went from
"users should not do" =>
"implementation can't keep user from doing" =>
"implementation must support" =>
"users can therefore depend on" =>
"users should feel free to do".
Only "must" and "shall", he would explain, is worth saying at all.
And probably this leads to a more readable standard.
But I think it leads to a lot of bad code.
I still think "should" has its place in reducing the statistical
likelihood of use of bad things, without outright disallowing it.
After all, if you took a literal reading, there's no point in deprecating
things, since deprecation effectively allows stuff. But we all know that
there are shades of gray whether or not they are testable--perhaps because
there are things not testable.
Glad to to see you're back, Kent.
To me, comp.lang.lisp was kind of incomplete without your posts, like
it missed something innate.
--
Vladimir Zolotykh
Pascal Costanza <··@p-cos.net> writes:
> doug wrote:
>
> > "It is an error to use function on a function name that does not
> > denote a function in the lexical environment in which the function
> > form appears. Specifically, it is an error to use function on a symbol
> > that denotes a macro or special form. An implementation may
> > choose not to signal this error for performance reasons, but
> > implementations are forbidden from defining the failure to signal an
> > error as a useful behavior."
>
>
> What does the last sentence of the quoted passage say?
My interpretation is that it really is more of a constraint on both
extensions and thus, indirectly, on the documentation of an
implementation. In other words, I would interpret the restriction not
so much as on what the implementation may DO, but rather on what they
can legitimately claim to do.
There are other places in the specfiication where implementations are
given scope to define the effects of some operation. Here the
implication seems to me that the behavior is defined to be an ERROR,
although one that need not be signaled. However, there shouldn't be any
attempt to make the lack of an error signaling requirement into an
implementation extension feature.
In practice, I would expect the effects in any given implementation to
be predictable and repeatable, but there is a restriction on any claim
that this is supposed to be a good thing (i.e., a feature) rather than
just an unchecked error.
--
Thomas A. Russ, USC/Information Sciences Institute
I have to say I am now confused when my lisp implementation, SBCL in
this case, does not produce the result from the text that I am reading.
Another example from the book shows that an unquoted lambda at the
top-level would produece an error:
> (lambda (n) (* n 10))
Error: Undefined function LAMBDA
But when I tried this in sbcl 0.9.13, I got this:
CL-USER> (lambda (n) (* n 10))
#<FUNCTION (LAMBDA (N)) {AD1FD5D}>
I don't have access to other lisp implementation at this moment, but
can someone help me find out what results would be in others?
At last, is there a simple, not CLHS-ish, explanation on why I am
seeing different behaviors here? Will this cause non-portable code?
Doug
doug <·········@yahoo.com> wrote:
+---------------
| ...is there a simple, not CLHS-ish, explanation on why I am seeing
| different behaviors here?
+---------------
Not really. Any explanation would almost *have* to invoke the CLHS, since
the inclusion of the LAMBDA *macro* [as opposed to the *symbol* LAMBDA]
is one of those things that was added to the ANSI Common Lisp Standard
[which the CLHS mirrors] relatively late in the game, as I understand it.
Compare:
http://www.lisp.org/HyperSpec/Body/mac_lambda.html
and:
http://www.lisp.org/HyperSpec/Body/sym_lambda.html
+---------------
| I have to say I am now confused when my lisp implementation, SBCL in
| this case, does not produce the result from the text that I am reading.
| Another example from the book shows that an unquoted lambda at the
| top-level would produece an error:
| > (lambda (n) (* n 10))
| Error: Undefined function LAMBDA
+---------------
The text that you are reading is not describing ANSI Common Lisp, but
"some other" Lisp. Your example is required to work [that is, give results
similar (see below) to what SBCL did] in a Common Lisp. You can probably
work around this problem by using the example macro definition of LAMBDA
given at the bottom of the first URL above.
+---------------
| But when I tried this in sbcl 0.9.13, I got this:
| CL-USER> (lambda (n) (* n 10))
| #<FUNCTION (LAMBDA (N)) {AD1FD5D}>
+---------------
This[1] is indeed what you should expect from any implementation
that purports to conform with ANSI Common Lisp. It is certainly
what you will get from SBCL, CMUCL, CLISP, Corman Lisp, Allegro
Common Lisp, Lispworks, etc., etc., etc.
-Rob
[1] Modulo implementation variations in PRINT-NOT-READABLE-OBJECT
and whether or not REPL input is automatically compiled, e.g.,
CLISP will say #<CLOSURE :LAMBDA (N) (* N 10)> and CMUCL will
say #<Interpreted Function (LAMBDA (N) (* N 10)) {484D6CE9}>.
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607