Static Typing in LISP? (was Re: The true faith)

[Francois-Rene Rideau]

Jochen Schmidt <jsc@dataheaven.de> writes on comp.lang.lisp:
> I think that Common Lisp somewhat proved
> that dynamic typing works for _really_ large software systems.
>
Oh, well, there have been huge systems in C++ or COBOL, too.
So the argument should rather be one of cost/benefits
(the estimation of which is indeed partly subjective):
how much does it cost (in months, unit of proficiency, kloc, etc., 
ultimately, dollar) to achieve how much features that are worth what
(in fame, brand recognition, community building, number of customers, etc.,
ultimately, dollar)?

>> LISP usually lacks a way to turn typing on.
> Your first sentence sounds as if you think Lisp is "untyped" - I know that
> you know better but can you explain what you meant?
>
Indeed, this sentence as stated is incorrect.
What I meant is that there is no (standard) way in LISP to have the system
enforce any kind of rich static type system. Let me expand on that.
A rich static type system is a way to attach some non-trivial invariants
to the context in which some objects and functions will be used.

Christopher Browne suggested that CMUCL and Stalin would be counter-examples.
Stalin certainly isn't -- as far as I know, it won't enforce any kind of
user-supplied type declaration; it will infer a "type" for every program;
any invariant enforced as to the context of use of a given object is trivial.
CMUCL comes much closer, since it is possible to declare types, and have
the system enforce them, although it requires quite some familiarity with
the system so as to understand how to use declarations to *statically*
enforce invariants -- which implies filtering the CMUCL warnings to detect
whether any inconsistency was detected. In addition to such usability
issues, the richness of type-system enforceable by CMUCL its a far cry
from that of the simplest ML variant.

>> Also, SEXP feels like
>> quite a suboptimal syntax for specialized sublanguages like the type
>> language, or the language of objects of a given type.
>
> Furthermode you lost me on why SEXPs are a suboptimal syntax for
> sublanguages like the type language or the language of objects of a given
> type. I don't see any fundamental problems in using an SEXP syntax for a
> type sublanguage.
>
It's indeed not a "fundamental" problem, but an important usability problem.
As an exercise, just try to write ML programs with a SEXP syntax,
which Macro Antoniotti suggested in a mail would have made *ML
better languages. It's definitely possible - and actually, the original
ML interpreter and the first ML compilers were written in LISP, and
there was a internal LISP representation for terms. But there's a reason
why ML users did not just stick to such internal representation.
Not only do you end up using noticeably more characters,
but the result is rather unwieldy, unless you are writing deep macros,
as with camlp4. Note that I'm not claiming that a SEXP syntax be dropped
altogether (as was the case with Dylan), but that there are times when
a specialized syntax is preferrable (which I presume is precisely
the reason why CL has reader-macros).

As for the CL syntax (declare (type Tfoo bar)), defended by Christopher
Browne, apart from its not having a semantic of system-enforcement
(a variant certainly could), it has the syntactical disadvantage of
not being at point of declaration of the declared variable bar.
A syntax as practical as ML would be to have something like (the Tfoo bar)
in lambda lists as well as in positive terms, although once again
with semantics of a system-enforcement rather than user-enforcement.

My conclusion would be that the lack of rich strong static typing in LISP
is certainly a disadvantage, and that though extending LISP with such typing
is at least conceivable, for practical reasons it would probably lead to a
language that, while hopefully retaining enough of the distinctive
characteristics of LISP that we like to still be called a LISP, would
probably also be noticeably different from existing LISPs, and largely
incompatible too, both semantically and syntactically. 
Would such a beast be desirable? I think it would be worth a try,
and I intend to try, one of these days.

Yours freely,

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
[  TUNES project for a Free Reflective Computing System  | http://tunes.org  ]
	It is a profoundly erroneous truism, repeated by all copy-books and
by eminent people when they are making speeches, that we should cultivate
the habit of thinking about what we are doing.  The precise opposite is the
case.  Civilization advances by extending the numbers of important operations
which we can perform without thinking about them.  Operations of thought are
like cavalry charges in battle -- they are strictly limited in number, they
require fresh horses, and must only be made at decisive moments.
		-- Alfred North Whitehead