Thomas Gagne wrote:
> CL-USER> (list 1 2 3)
> (1 2 3)
> CL-USER> '(1 2 3)
> (1 2 3)
>
> Same thing?
Yes, but the first constructs the list from its three arguments,
while the second one creates a "constant" list. This means that
you can't destructively modify the second list, AFAIK, but that's
something you should mostly avoid, anyway.
--
No man is good enough to govern another man without that other's
consent. -- Abraham Lincoln
Ulrich Hobelmann <···········@web.de> writes:
> Thomas Gagne wrote:
> > CL-USER> (list 1 2 3)
> > (1 2 3)
> > CL-USER> '(1 2 3)
> > (1 2 3)
> > Same thing?
>
> Yes, but the first constructs the list from its three arguments, while
> the second one creates a "constant" list. This means that you can't
> destructively modify the second list, AFAIK, but that's something you
> should mostly avoid, anyway.
QUOTE doesn't create anything.
In:
(QUOTE (1 2 3))
it's the reader who creates the list. The reader produces this data
structure:
+-----------------------------------------------+
| (QUOTE (1 2 3)) |
| |
| +---+---+ +---+---+ |
| | a | b |-->| c |NIL| |
| +---+---+ +---+---+ |
| | | |
| v v |
| +-------+ +---+---+ +---+---+ +---+---+ |
| | QUOTE | | * | * |-->| * | * |-->| * |NIL| |
| +-------+ +---+---+ +---+---+ +---+---+ |
| | | | |
| v v v |
| +---+ +---+ +---+ |
| | 1 | | 2 | | 3 | |
| +---+ +---+ +---+ |
+-----------------------------------------------+
where you can see that the list is already "created".
When the evaluator executes the QUOTE special operator, it returns the
(1 2 3) list itself, that is, directly the pointer "c".
It's unspecified and implementation dependent whether you can or
cannot modify it. You should not, and cannot rely on consistent
behavior, but, in clisp:
(defun l () '(1 2 3))
(compile 'l)
(print (l))
(setf (car (l)) 4)
(print (l))
(print (function-lambda-expression (function l)))
prints:
(1 2 3)
(4 2 3)
(LAMBDA NIL '(4 2 3))
--
__Pascal Bourguignon__ http://www.informatimago.com/
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d? s++:++ a+ C+++ UL++++ P--- L+++ E+++ W++ N+++ o-- K- w---
O- M++ V PS PE++ Y++ PGP t+ 5+ X++ R !tv b+++ DI++++ D++
G e+++ h+ r-- z?
------END GEEK CODE BLOCK------
In article <······················@wideopenwest.com>,
Thomas Gagne <······@wide-open-west.com> wrote:
> CL-USER> (list 1 2 3)
> (1 2 3)
> CL-USER> '(1 2 3)
> (1 2 3)
>
> Same thing?
(defvar *saved1*)
(defparameter *first-time-1* t)
(defun test1 ()
(let ((thing '(1 2 3)))
(if *first-time-1*
(setq *saved1* thing
*first-time-1* nil)
(eq thing *saved1*))))
(defvar *saved2*)
(defparameter *first-time-2* t)
(defun test2 ()
(let ((thing (list 1 2 3)))
(if *first-time-1*
(setq *saved1* thing
*first-time-1* nil)
(eq thing *saved1*))))
(test1)
(test1) => T
(test2)
(test2) => NIL
Every time you call LIST, it conses a brand new list, guaranteed not to
be EQ to the one that was consed earlier and saved in *SAVED2*.
Also, compile the functions and then compare (time (dotimes (i 1000)
(test1))) and (time (dotimes (i 1000) (test2))), taking particular note
of the amount of consing.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
In the last exciting episode, Thomas Gagne <······@wide-open-west.com> wrote:
> CL-USER> (list 1 2 3)
> (1 2 3)
> CL-USER> '(1 2 3)
> (1 2 3)
>
> Same thing?
Yes, one is shorthand for the other.
--
(format nil ···@~S" "cbbrowne" "gmail.com")
http://linuxdatabases.info/info/emacs.html
Signs of a Klingon Programmer #11: "This machine is a piece of GAGH! I
need dual Pentium processors if I am to do battle with this code!"
Christopher Browne <········@acm.org> writes:
> In the last exciting episode, Thomas Gagne <······@wide-open-west.com> wrote:
>> CL-USER> (list 1 2 3)
>> (1 2 3)
>> CL-USER> '(1 2 3)
>> (1 2 3)
>>
>> Same thing?
>
> Yes, one is shorthand for the other.
What? Not really. '(1 2 3) returns a list created by the reader while
(list 1 2 3) creates a list at runtime. The cons cells that make up
former can't be modified without entering the realm of undefined
behavior. At least in compiled code--and since the REPL may be
implemented to compile each expression I'd say it's safe to assume
that's possibly the case even here.
-Peter
--
Peter Seibel ·····@gigamonkeys.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel wrote:
> Christopher Browne <········@acm.org> writes:
>
>
>>In the last exciting episode, Thomas Gagne <······@wide-open-west.com> wrote:
>>
>>>CL-USER> (list 1 2 3)
>>>(1 2 3)
>>>CL-USER> '(1 2 3)
>>>(1 2 3)
>>>
>>>Same thing?
>>
>>Yes, one is shorthand for the other.
>
>
> What? Not really. '(1 2 3) returns a list created by the reader while
> (list 1 2 3) creates a list at runtime. The cons cells that make up
> former can't be modified without entering the realm of undefined
> behavior. At least in compiled code--and since the REPL may be
> implemented to compile each expression I'd say it's safe to assume
> that's possibly the case even here.
I'm slightly disturbed that it's so easy to do something badly wrong
like this in lisp.
Thanks to static typing, even c++ won't let you compile
"123"[0] = '4';
Seriously though, is there any fundamental reason why lisp couldn't mark
the internal structure of '(1 2 3) as constant? So any attempt to
modify it can be caught. Or is the whole 'constant' typing thing too
recent a trend to have been made part of common lisp?
g.a.
Glen Able wrote:
> Peter Seibel wrote:
> > What? Not really. '(1 2 3) returns a list created by the reader
while
> > (list 1 2 3) creates a list at runtime. The cons cells that make up
> > former can't be modified without entering the realm of undefined
> > behavior. At least in compiled code--and since the REPL may be
> > implemented to compile each expression I'd say it's safe to assume
> > that's possibly the case even here.
>
> I'm slightly disturbed that it's so easy to do something badly wrong
> like this in lisp.
>
> Thanks to static typing, even c++ won't let you compile
> "123"[0] = '4';
>
> Seriously though, is there any fundamental reason why lisp couldn't
> mark the internal structure of '(1 2 3) as constant? So any attempt
> to modify it can be caught. Or is the whole 'constant' typing thing
> too recent a trend to have been made part of common lisp?
It is indeed a Lisp gotcha, which a number of people want replaced. By
(say) signalling an error.
As I understand, it was implementation-dependent so people could store
these things in ROM, while others could do... whatever madness.
There's a few Lisp gotchas:
* nth/elt/gethash argument orders
* macro overuse
* loop bodies shouldn't be before variable init things
* defvar is more evil than people naively think
* PAIP examples are tricky to run on today's CL
* CL implementations aren't that alike
* the spec is evil in blithely using setf on unbound vars... I would
even claim it's willy-nilly
Jock Cooper <·····@mail.com> writes:
> "Tayssir John Gabbour" <···········@yahoo.com> writes:
>> * defvar is more evil than people naively think
>
> Care to elaborate?
Presumably he's refering to the fact that DEFVAR (and DEFPARAMETER)
make the symbol used as the variable name pervasively special. Thus
the importance of following the *star-naming-convention*.
-Peter
--
Peter Seibel ·····@gigamonkeys.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel wrote:
> Jock Cooper <·····@mail.com> writes:
>
> > "Tayssir John Gabbour" <···········@yahoo.com> writes:
> >> * defvar is more evil than people naively think
> >
> > Care to elaborate?
>
> Presumably he's refering to the fact that DEFVAR (and DEFPARAMETER)
> make the symbol used as the variable name pervasively special. Thus
> the importance of following the *star-naming-convention*.
Sorry, I was being horribly unclear since I typed that too fast, and it
was crazy to say it was "evil." Just that I remember people on usenet
have been bitten by:
USER> (defvar *blah* 0)
...
USER> *blah*
0
USER> (defvar *blah* "nevermind")
...
USER> *blah*
0
There are of course times people enjoy this behavior...
+ "Tayssir John Gabbour" <···········@yahoo.com>:
| Peter Seibel wrote:
| > Jock Cooper <·····@mail.com> writes:
| >
| > > "Tayssir John Gabbour" <···········@yahoo.com> writes:
| > >> * defvar is more evil than people naively think
| > >
| > > Care to elaborate?
| >
| > Presumably he's refering to the fact that DEFVAR (and DEFPARAMETER)
| > make the symbol used as the variable name pervasively special. Thus
| > the importance of following the *star-naming-convention*.
|
| Sorry, I was being horribly unclear since I typed that too fast, and it
| was crazy to say it was "evil." Just that I remember people on usenet
| have been bitten by:
|
| USER> (defvar *blah* 0)
| ...
| USER> *blah*
| 0
| USER> (defvar *blah* "nevermind")
| ...
| USER> *blah*
| 0
|
| There are of course times people enjoy this behavior...
Oh that. Well, that is /intended/ behaviour. One should use
defparamater instead, if the /other/ behaviour is desired.
I think the intention for the defvar behaviour is that you would
typically use it in a source file to provide an initial value for the
variable. Interactively, you may have modified the value later, and
you might not wish for the initial value to reappear in case you
reload the file because you changed some function definition.
But I think perhaps it would be wise for people to use defparameter
rather than defvar when discussing some example, particularly when
newbies are present.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Debating gives most of us much more psychological satisfaction
than thinking does: but it deprives us of whatever chance there is
of getting closer to the truth. -- C.P. Snow
From: Marcin 'Qrczak' Kowalczyk
Subject: Re: pcl: is LIST the same as '?
Date:
Message-ID: <87pswrht77.fsf@qrnik.zagroda>
Glen Able <·········@gmail.com> writes:
> I'm slightly disturbed that it's so easy to do something badly wrong
> like this in lisp.
>
> Thanks to static typing, even c++ won't let you compile
> "123"[0] = '4';
But it will compile:
char *s = "123";
s[0] = '4';
It's as bad as in Lisp.
> Seriously though, is there any fundamental reason why lisp couldn't
> mark the internal structure of '(1 2 3) as constant?
I guess it's efficiency. In some Lisp implementations cons cells have
a special, optimized representation, e.g. avoiding a header which is
present in all other heap-allocated objects. There is often no room
for a second such representation, and anyway it would complicate
functions operating on lists by forcing them to recognize two cases.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> writes:
>Glen Able <·········@gmail.com> writes:
>
>> I'm slightly disturbed that it's so easy to do something badly wrong
>> like this in lisp.
>>
>> Thanks to static typing, even c++ won't let you compile
>> "123"[0] = '4';
>
>But it will compile:
> char *s = "123";
> s[0] = '4';
>
>It's as bad as in Lisp.
In your example, it's exactly the same as with Lisp.
But consider:
char t[] = "123";
t[0] = '4';
which will work.
mkb.
Matthias Buelow wrote:
> Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> writes:
>
>
>>Glen Able <·········@gmail.com> writes:
>>
>>
>>>I'm slightly disturbed that it's so easy to do something badly wrong
>>>like this in lisp.
>>>
>>>Thanks to static typing, even c++ won't let you compile
>>>"123"[0] = '4';
>>
>>But it will compile:
>> char *s = "123";
>> s[0] = '4';
>>
>>It's as bad as in Lisp.
>
>
> In your example, it's exactly the same as with Lisp.
> But consider:
>
> char t[] = "123";
> t[0] = '4';
>
> which will work.
>
> mkb.
As I understand it the standard forbids that, because you're silently
'casting away const' (although most compilers seem to be in denial ;)
Better to write:
const char* s = "123";
Then, to modify the string, you're supposed to be very explicit about
what you're doing, i.e. something hideous like:
(const_cast<char*>(s))[0] = '4';
Glen Able <·········@gmail.com> writes:
>As I understand it the standard forbids that, because you're silently
>'casting away const' (although most compilers seem to be in denial ;)
>Better to write:
>
>const char* s = "123";
>
>Then, to modify the string, you're supposed to be very explicit about
>what you're doing, i.e. something hideous like:
>
>(const_cast<char*>(s))[0] = '4';
No. The difference between "char *s = ..." and "char s[] = ..." is
that the first creates a pointer to an unnamed char array (the string
constant), and initializes the pointer (then pointing to the char
array). The second form creates a mutable, named char array, and
initializes it with the characters from the string constant (which
only exists in the compiler's data structures during compilation).
The difference can be observed in the generated object code because
many compilers will, in the first case, relocate the string constant
that is pointed to by s into the executable's text segment, therefore
making it unwritable (on Unix, writing to it will usually result in
a "bus error" signal).
In the second case, the string resides, as an array, in the data
segment, or on the stack (in the case of auto variables).
[Sorry folks, this really doesn't belong to c.l.lisp anymore.]
mkb.
From: Kristian Elof Sørensen
Subject: Re: pcl: is LIST the same as '?
Date:
Message-ID: <4264F692.8050704@image.dk>
Glen Able wrote:
> Peter Seibel wrote:
>
>> Christopher Browne <········@acm.org> writes:
>>
>>
>>> In the last exciting episode, Thomas Gagne
>>> <······@wide-open-west.com> wrote:
>>>
>>>> CL-USER> (list 1 2 3)
>>>> (1 2 3)
>>>> CL-USER> '(1 2 3)
>>>> (1 2 3)
>>>>
>>>> Same thing?
>>>
>>>
>>> Yes, one is shorthand for the other.
>>
>>
>>
>> What? Not really. '(1 2 3) returns a list created by the reader while
>> (list 1 2 3) creates a list at runtime. The cons cells that make up
>> former can't be modified without entering the realm of undefined
>> behavior. At least in compiled code--and since the REPL may be
>> implemented to compile each expression I'd say it's safe to assume
>> that's possibly the case even here.
>
>
> I'm slightly disturbed that it's so easy to do something badly wrong
> like this in lisp.
>
> Thanks to static typing, even c++ won't let you compile
> "123"[0] = '4';
>
> Seriously though, is there any fundamental reason why lisp couldn't mark
> the internal structure of '(1 2 3) as constant? So any attempt to
> modify it can be caught. Or is the whole 'constant' typing thing too
> recent a trend to have been made part of common lisp?
>
> g.a.
Well lisp started with the insight that starting with only a small set
of functions http://lib.store.yahoo.com/lib/paulgraham/jmc.lisp a very
powerfull and usefull programming language could be made. Kind of like
the axioms of say classical geometry.
In many other languages eg. c and perl, the language was built the other
way aroud with somebody facing a practical programming task, and
creating a language that would help him complete the task.
For c it was building enough of an operating system etc. to make a
certain game run on an abandoned computer, for perl it was to relieve
the boredom of having to manually operate a text mode user interface
over an extremely slow encrypted serial channel, by automating the task.
Both kinds of languages have strange and surpricing behavior that can be
counterproductive and lead to ugly bugs, however in lisp these behaviors
tends to be a function of the form of the axioms and the way the
language was derived from them, whereas in most other languages these
behaviours tend to be a caused by the form of the language being build
to follow the functions needed to solve the task the language was
originally built to solve rather than the one you are trying to solve.
See you in Amsterdam!
Kristian
Thomas Gagne <······@wide-open-west.com> writes:
>
> CL-USER> (list 1 2 3)
> (1 2 3)
> CL-USER> '(1 2 3)
> (1 2 3)
>
> Same thing?
Not really. In the particular case at hand, they are the same but
that's only because numbers happen to be self-evaluating in Lisp.
To see the difference, you need to try this with symbols:
Consider
'(a b c)
versus
(list 'a 'b 'c)
There are also other, more subtle, differences because the quoted form
is a constant and thus requires that you not modify the list structure.
But that is a bit more of an advanced topic.
The key is to understand the notions of evaulation and quoting, since
that is a fundamental part of the Lisp language and must be mastered.
For another example, consider:
(let ((a 3) (b "Bee") (c 'sea))
(list a b c))
(let ((a 3) (b "Bee") (c 'sea))
'(a b c))
--
Thomas A. Russ, USC/Information Sciences Institute
Thomas Gagne asked:
CL-USER> (list 1 2 3)
(1 2 3)
CL-USER> '(1 2 3)
(1 2 3)
Same thing?
* (let* ((arg-form '(1 2 3))
(list-form (cons 'list arg-form))
(quote-form (list 'quote arg-form)))
(format t "~&Is ~A from ~A the very same list as ~A? ~:[No~;Yes~]."
(eval list-form)
list-form
arg-form
(eq (eval list-form) arg-form))
(format t "~&Is ~A from ~A the very same list as ~A? ~:[No~;Yes~]."
(eval quote-form)
quote-form
arg-form
(eq (eval quote-form) arg-form)))
Is (1 2 3) from (LIST 1 2 3) the very same list as (1 2 3)? No.
Is (1 2 3) from '(1 2 3) the very same list as (1 2 3)? Yes.
NIL
*
Alan Crowe
Edinburgh
Scotland