Language standards for LispOS

[Marc Wachowitz]

Chris Bitmead uid <chris.bitmead@alcatel.com.au> (x22068) wrote:
> > However, if we would make
> > CONS-IMMUTABLE a supertype of CONS, we would break any program which
> > assumes that what it gets is a CONS, even if it does only read it. 
> 
> Why would it break it? I just can't see how. In a staticly typed
> language, sure I can see that. But in a dynamically typed language???

Typing in Common Lisp isn't entirely dynamic. Declarations are (mostly)
static information for the translator, and dynamic behaviour is also
to a considerable degree based on subtyping. If we made quoted lists
immutable of type CONS-IMMUTABLE, and let that type be a supertype of
CONS instead of a subtype, dynamic type testing with CONSP or TYPEP
or CLASS-OF / TYPE-OF and SUBTYPEP wouldn't work, generic function
dispatching for CONS wouldn't work, program parts declaring to receive
a CONS - which they were entitled to expect - would have undefined
consequences (that's what you get from violating declarations), and
you could trash just about any formerly useful program. Even something
as simple and innocent as the following wouldn't work any more:

(DEFUN MY-LENGTH (X)
  (IF (CONSP X)
      (1+ (MY-LENGTH (CDR X)))
      0))
(MY-LENGTH '(1 2 3 4 5))  =>  0

Just forget it.

[in another mail]
> I'm not familar with this mutablep thingy. Under what circumstances
> does common lisp specify that a cons cell is immutable?

Every literal object is immutable, i.e. whatever is either inside
a QUOTE special form, or simply happens to be used as self-evaluating
literal (e.g. strings, arrays, structures, hash tables, and so on).
The results of some standard functions (like SYMBOL-NAME) are also
immutable. Macros are not allowed to modify their arguments, so
what's read by LOAD and COMPILE-FILE can be made immutable (unless
we really want to modify the parts which aren't possibly seen by
macros - but I doubt whether that effort would be a good idea,
particularly as COMPILE or EVAL must not modify their arguments,
and we'll probably want to share most of theses translators).
There are probably some further cases, which I currently don't
remember. All this amounts to quite a lot of data, and making it
actually immutable, and having the compiler and runtime system
know about it, has considerable advantages - for correctness,
storage consumption (due to not having to make lots of copies to
prevent damage for shared data, in case someone changes it anyway
and the implementation doesn't prevent it), and many optimizations.


For details, see the Common Lisp HyperSpec - the ANSI Common Lisp
specification in HTML, with extensive links, including documents
about discussions of many decisions made during the standardization
process, providing additional background about various concerns for
changes/clarifications by ANSI. Edited by Kent Pitman, who was also
editor of the ANSI standard. Available for free from Harlequin:
http://www.harlequin.com/HyperSpec

-- Marc Wachowitz <mw@ipx2.rz.uni-mannheim.de>