GNU bug report logs - #40671
[DOC] modify literal objects

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, Mattias Engdegård <mattiase <at> acm.org>, 40671 <at> debbugs.gnu.org, Richard Stallman <rms <at> gnu.org>, ke.vigouroux <at> laposte.net
Subject: bug#40671: [DOC] modify literal objects
Date: Wed, 29 Apr 2020 03:14:22 +0300

On 29.04.2020 03:04, Paul Eggert wrote:
> It's reasonable to have compile-time checking in a statically-typed language,
> though (as the above quote notes) the checking isn't adequate for C++ and one
> can get undefined behavior anyway in that language.

All the undefined-behavior stuff in the language is part of backward 
compatibility with C. Like I said, the same argument that says "you can 
change a const in C++" also says "string and int and void are basically 
the same type".

> And we could add some
> similar compile-time checking for the Elisp byte-compiler: it could warn about
> misuses like (aset "abc" 0 ?d), for example.

Not the worst idea. Won't work: it's a dynamic language. Hence the 
example of how a similar problem was dealt with in a fellow dynamic 
language that I wrote about a couple of messages ago.

> However, any such compile-time checking would be either too restrictive (with
> false positives)

The "too restrictive" end of the spectrum will result in prohibiting the 
user from modifying any and all conses.

> or only partial (with false negatives) or both (as in C++). So
> it wouldn't be an adequate substitute for documenting that some objects should
> not be changed.

With runtime checks, it could. But that might be too costly.

> I recall your using "literal object" but that's not a good choice of wording
> because the problem can occur with objects that are not literally present in any
> source code.

"Any object that is part of a literal value". You can probably extend 
that sentence to be exhaustive.

> By "elsewhere" I meant in other language documentation (C/C++/etc.), not
> elsewhere in the emacs-27 manual.

In "etc", you mentioned Common Lisp previously. Any idea how it deals 
with that problem?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.