Literal Lists

[FAU]

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.

[Warren Wilkinson]

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?

[FAU]

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...

[churib]

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))

[Kompottkin]

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.

[FAU]

Yes it is Let Over Lambda.

[Paul]

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.

[Kompottkin]

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.)

[Paul]

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 )

[Kompottkin]

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. )