Language standards for LispOS

[Marc Wachowitz]

Chris Bitmead uid <chris.bitmead@alcatel.com.au> (x22068) wrote:
> Meyer says that a sub-class may decrease the strength of preconditions
> and increase the strength of postconditions. In other words, a
> subclass can expect less from the caller and promise more in return,
> but not the other way around.

This is exactly what I'm suggesting; you're just making a false guess
about the contract, i.e. the ANSI Common Lisp specification.

> A precondition to a method which mutates a cons cell is naturally that
> the cons cell be mutable.

We're not talking about natural cell mutation (which does only matter for
biology), but about the type CONS and (SETF (CAR X) Y) as defined in the
ANSI Common Lisp specification. In that context, what you write is just
_wrong_, even if some implementation happens to protect you from crashing
the system with such _errors_. The precondition for (SETF (CAR X) Y) is
_not_ just (CONSP X), but (AND (CONSP X) (MUTABLEP X)), where (MUTABLEP X)
means that mutation of X is allowed, as specified for ANSI Common Lisp.

Unfortunately, you don't get a test function MUTABLEP to call in programs,
and even in safe mode, the implementation isn't required to check this -
but that has no consequence at all for the semantic requirements (you can
read this from Meyer, too - Eiffel's checked precondition is a subset of
a complete precondition). What a subclass CONS-IMMUTABLE does is simply
making the attempted modification more robust, by promising to signal a
condition if (NOT (MUTABLEP X)).

This does _not_ prevent anything which would have been _correct_ before!

> If you strengthen pre-conditions then you've just
> broken all your old code, which may have been assuming that cons cells
> are mutable.

In that case, such old code was already broken, and I'm only improving
robustness by signalling an appropriate condition, instead of ignoring
the error or causing arbitrary damage ("undefined consequences").

> If you do it the other way though, and make cons-immutable a super
> class of cons, everything is fine.

You couldn't use this stuff in any place where Common Lisp requires
type CONS, e.g. for standard literals, or for standard functions
returning immutable CONSes, even though these are defined as immutable.

That would defeat the whole purpose of having such a type at all -
using instances of CONS-IMMUTABLE with standard code wouldn't work.
It would make code which was perfectly ok before fail, since CONSP
would be false for these instances - or some declarations asserting
type CONS for such an entity would even make the program's behaviour
undefined. That's not fine at all.

We're not talking about designing some completely new language (where
it would be reasonable to create a type hierarchy as you'd prefer),
but about an extension of Common Lisp. Otherwise, let's do something
completely different ;-)

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