Literal Lists

Discussion of Common Lisp

Literal Lists

Postby FAU » Fri Feb 11, 2011 1:50 pm

I've been reading a little bit in LOL. Please look at this:

;;; From LOL, chapter 4, page 80.

(defvar to-splice '(B C D))

`(a ,.to-splice e)

to-splice ; => (B C D E)

Here apparently a literal list is being modfied and we all know that the results are undefined. Either this is a bad example or I'm completely missing something here.
FAU
 
Posts: 24
Joined: Tue Nov 02, 2010 2:47 am
Location: Edmonton, AB

Re: Literal Lists

Postby Warren Wilkinson » Sat Feb 12, 2011 2:52 am

I would think a literal list being modified would be defined as 'the literal list gets modified' =).

Must be something to do with the ,. operator... how does the ,@ operator fare?
Need an online wiki database? My Lisp startup http://www.formlis.com combines a wiki with forms and reports.
User avatar
Warren Wilkinson
 
Posts: 116
Joined: Tue Aug 10, 2010 11:24 pm
Location: Calgary, Alberta

Re: Literal Lists

Postby FAU » Sat Feb 12, 2011 3:54 am

Well sure the ,@ is non-destructive and conses a new list.

I was just wondering that the book shows this example without saying anything about it's undefined effects. (Well it does so in the next example which is similar.) As somebody who's new to LISP thinks then he might have misunderstood something somewhere...
FAU
 
Posts: 24
Joined: Tue Nov 02, 2010 2:47 am
Location: Edmonton, AB

Re: Literal Lists

Postby churib » Sat Feb 12, 2011 5:32 am

Mostly "LOL" is related to Land of Lisp :)

edit: the following refers to Let over Lambda
And yes, there is a warning in the book with the example calling this function twice:
(defun dangerous-use-of-bq ()
`(a ,.'(b c d) e))
Last edited by churib on Mon Feb 14, 2011 1:59 am, edited 1 time in total.
churib
 
Posts: 6
Joined: Tue Feb 08, 2011 10:22 am

Re: Literal Lists

Postby Kompottkin » Sun Feb 13, 2011 4:37 am

I gather you're talking about Let over Lambda? You're right, the consequences of modifying literals are undefined (this is explicitly noted in the CLHS), and I think it's wrong not to note this somewhere in the text.

Overall, I have mixed feelings about the book. On the one hand, it's interesting and unique, but on the other hand, it contains a couple of questionable design decisions and tends to ignore subtle issues that you ought to be aware of as a Lisp programmer. Modification of literals is one. Another is this talk about “duality of syntax” being a reason not to lexically distinguish special variables from lexical ones, which is problematic from an engineering point of view, as noted in numerous texts on Lisp style. (And in any case, duality of syntax is preserved by using earmuffs, so I don't really get the reasoning anyway.)

That said, I haven't yet worked through the book. Perhaps the issues are addressed somewhere rather than dismissed. Also, its virtues might well be much greater than its flaws. It is an intriguing piece of work, after all.
User avatar
Kompottkin
 
Posts: 94
Joined: Mon Jul 21, 2008 7:26 am
Location: München, Germany

Re: Literal Lists

Postby FAU » Sun Feb 13, 2011 1:09 pm

Yes it is Let Over Lambda.
FAU
 
Posts: 24
Joined: Tue Nov 02, 2010 2:47 am
Location: Edmonton, AB

Re: Literal Lists

Postby Paul » Wed Jun 22, 2011 3:35 am

FAU wrote:I've been reading a little bit in LOL. Please look at this:

;;; From LOL, chapter 4, page 80.

(defvar to-splice '(B C D))

`(a ,.to-splice e)

to-splice ; => (B C D E)

Here apparently a literal list is being modfied and we all know that the results are undefined. Either this is a bad example or I'm completely missing something here.


[I know this is old, but...]

Presumably you're supposed to be typing this at the REPL, so there is no problem (the results are perfectly well defined as long as you don't file-compile it). In some sense it's a "bad example", in that you don't want to teach bad habits...but on the other hand, I think it's better to teach people to understand how things really work, rather than just "cargo cult" programming (and get people saying things like "we all know the results are undefined" when you do this kind of thing...which is not actually true), anyway, so "bad examples" can be useful/good.
Paul
 
Posts: 106
Joined: Tue Jun 02, 2009 6:00 am

Re: Literal Lists

Postby Kompottkin » Fri Jun 24, 2011 4:06 am

Paul wrote:Presumably you're supposed to be typing this at the REPL, so there is no problem (the results are perfectly well defined as long as you don't file-compile it).


Well...

“The consequences are undefined if literal objects (including quoted objects) are destructively modified.” (CLHS, Special Operator QUOTE)

What you're probably thinking of is the fact that literals may be coalesced only when doing file compilation. However, literals may never be destructively modified, regardless of whether or not they have been coalesced.


In some sense it's a "bad example", in that you don't want to teach bad habits...but on the other hand, I think it's better to teach people to understand how things really work [...]


I agree with the general point you're making, but in this particular case, understanding how things really work includes understanding that there are important differences between a quoted list and a list constructed by user code, the former, after all, being a part of the program's code. (This is actually a pretty significant point, and I'm quite puzzled about the fact that I've never actually seen introductory material that explains it well. In fact, I suspect that figuring out why the CLHS page on the QUOTE operator is as short as it is might get one more than half-way towards grokking Lisp's evaluation model.)
User avatar
Kompottkin
 
Posts: 94
Joined: Mon Jul 21, 2008 7:26 am
Location: München, Germany

Re: Literal Lists

Postby Paul » Fri Jun 24, 2011 3:46 pm

Kompottkin wrote:
Paul wrote:Presumably you're supposed to be typing this at the REPL, so there is no problem (the results are perfectly well defined as long as you don't file-compile it).


Well...

“The consequences are undefined if literal objects (including quoted objects) are destructively modified.” (CLHS, Special Operator QUOTE)

What you're probably thinking of is the fact that literals may be coalesced only when doing file compilation. However, literals may never be destructively modified, regardless of whether or not they have been coalesced.


It's not just a matter of coalescing it with other similar lists, the file compiler can do other things, like putting it in read-only memory...but the REPL can never do such things, so in fact you can modify "literals"; it's perfectly well defined (the only thing that matters is what QUOTE does, and that's fully specified (i.e., it just returns the exact same object that appears as its argument), so there's no way quoted literals can behave in any way differently from unquoted objects...including those constructed at run-time. If the former were "undefined", so would the latter be, and then you'd have to stick to purely functional code :) )
Paul
 
Posts: 106
Joined: Tue Jun 02, 2009 6:00 am

Re: Literal Lists

Postby Kompottkin » Sat Jun 25, 2011 3:45 am

Paul wrote:It's not just a matter of coalescing it with other similar lists, the file compiler can do other things, like putting it in read-only memory...but the REPL can never do such things


(Emphasis mine.)

I don't believe the spec says that. See below.


so in fact you can modify "literals"; it's perfectly well defined


Again, the HyperSpec is very explicit in this regard:

“The consequences are undefined if literal objects (including quoted objects) are destructively modified.” (CLHS, Special Operator QUOTE)

“The consequences are undefined if literal objects are destructively modified.” (CLHS, 3.7.1 Modification of Literal Objects)

Finally, if still in doubt, see CLHS, Issue CONSTANT-MODIFICATION.


the only thing that matters is what QUOTE does, and that's fully specified


No, it's not the only thing that matters. In fact, QUOTE seems to me to be irrelevant. It's true that modifying the return value of (eval `(quote ,(list 1 2 3))) is (I believe) perfectly well-defined, but that's because in this case, the argument to quote is not a literal (while in (quote (1 2 3)), it is).

“The consequences are undefined if literal objects are destructively modified.” As far as I can see, that's all there is to it. (Of course, it wouldn't be the first time I misread the spec. :))
User avatar
Kompottkin
 
Posts: 94
Joined: Mon Jul 21, 2008 7:26 am
Location: München, Germany

Next

Return to Common Lisp

Who is online

Users browsing this forum: Google [Bot] and 3 guests

cron