bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#40671: [DOC] modify literal objects


From: Paul Eggert
Subject: bug#40671: [DOC] modify literal objects
Date: Fri, 1 May 2020 14:40:59 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0

On 4/30/20 8:13 PM, Dmitry Gutov wrote:
> On 29.04.2020 04:38, Paul Eggert wrote:
>> Here's a quote from CLtL2 (page 115):
>>
>> "it is an error to destructively modify any object that appears as a constant
>> in executable code, whether within a 'quote' special form or as
>> a self-evaluating form."
> 
> As Drew pointed out (and if I understood this correctly), the above
> specification leads to implementations that do raise an error when someone 
> tried
> to modify such a value.

Although those implementations conform to the Common Lisp spec, that's because
the spec explicitly says such behavior is undefined - which means
implementations can signal an error, dump core, or do whatever else they want.
See <https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node11.html>, which uses
"should" in the same sense the emacs-27 elisp manual uses "should". Here's a 
quote:

-----

When this book specifies that it "is an error" for some situation to occur, this
means that:

* No valid Common Lisp program should cause this situation to occur.

* If this situation occurs, the effects and results are completely undefined as
far as adherence to the Common Lisp specification is concerned.

* No Common Lisp implementation is required to detect such an error. Of course,
implementors are encouraged to provide for detection of such errors wherever
reasonable.

This is not to say that some particular implementation might not define the
effects and results for such a situation; the point is that no program
conforming to the Common Lisp specification may correctly depend on such effects
or results.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]