Language standards for LispOS

[Chris Bitmead uid(x22068)]

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

I thought that might be what you would say. There seems to be a simple
answer to this. Implement CONSP to be the same as CONSP-IMMUTABLE, and
have CONSP-MUTABLE to be a separate, new function. Makes sense anyway,
since both are semantically cons cells.

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

Well it seems to me that Common Lisp did the right thing assuming the
decision to not have different classes for mutable and immutable
things. But as soon as you decide you want mutable and immutable to
actually be different objects, then the Common Lisp decision is
completely wrong.

That's the danger of making big changes to a language without the
willingness to go the whole hog and do it right. I vote you either
choose between compatibility and doing it right. Neither choice is
wrong, but half-way is a mess.