Language standards for LispOS
Henry G. Baker
Wed, 21 May 1997 09:15:19 -0700 (PDT)
> 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 <email@example.com>
I don't think you can make an omelette without breaking a few
egg(head)s. If certain CL functions _should_ be returning immutable
conses, and if some program depends upon the fact that they don't,
then of course it should break.
Making distinctions where none were made before will require some
amount of change. The exact same thing happened when ANSI C forced C
programmers to start 'typing' arguments to functions. The vast
majority of code was ok, but there were some functions that had been
playing games, and explicit casting was required to fix the problem.
Under the new scenario, data structures have both a 'type', which is a
'shape', and a 'use', which indicates things like mutability.
Presumably the 'type' functions like CONSP continue to work, but we will
also need functions like MUTABLEP to determine 'use'.
Linear objects are very simple to handle, since linear
variables/symbols have to be 'marked' in the source code. Thus, you
would need something like '$X' instead of 'X' to indicate a linear
variable 'X'. I know that this sounds like we're headed back to
Fortran-66, but the lexical usage of linear variables is completely
different from the lexical usage of 'normal' variables (unlike the
situation with integer and float variables in Fortran-66), so it is
ok. Linear variables must have exactly one use, and this must be
statically obvious. I would make the default type of argument lists
to be _linear_, so &REST arguments that aren't marked with '$' are
coerced to immutable lists. (I'm not married to '$'; the English
pound symbol is probably more mnemonic, since it looks like a capital
So the complexity with things like CONSP you are referring to occurs
only with the mutable/immutable distinction.
www/ftp directory URL: