Re: Static/Strong/Implicit Typing

From: Gareth McCaughan (gareth.mccaughan_at_pobox.com)
Date: 01/28/04 

Date: 28 Jan 2004 00:35:17 +0000

"sajiimori" wrote:

> > Then I can't use the sequence functions of Common Lisp that
> > accept both lists and vectors. I can't use the nice flexible
> > arithmetic functions.
>
> You could if the functions had multiple versions, and the compiler inserted
> calls to the appropriate ones (since it has all the static type information
> it needs to make that determination).

So now you have a type system that allows functions to
have types like "'a -> 'a where 'a is 'b list or 'b vector"?

> > Next: I can't write macros any more. To define a macro,
> > you define a function that operates on source code.
> > And embedded in that source code there may be all kinds
> > of objects. Numbers of various kinds, symbols, cons cells
> > (for code or data), arrays, strings, blah, blah, blah.
> > This is not a situation that static type systems tend
> > to handle well.
>
> That is very important. I wonder why nobody else had mentioned it (that I
> saw anyway)?

Obviously because I'm so much cleverer than all the other
people who replied to you :-). Or, considerably more likely
(especially in view of who some of them are), because they
saw other problems that they regarded as more important.

> > Suppose we define a discriminated union
> > type that can contain anything that can appear literally
> > in source code, and then build our representation of code
> > out of that.
>
> This is what I was thinking.
>
> > (It would probably be necessary to forbid
> > user-defined types appearing here, but maybe that's not
> > so terrible.)
>
> Don't user-defined types have to be based on built-in types anyway?

Depends on what you mean by "based on", I suppose. If I say

    (defclass foo ...)

then FOO is a new type which isn't exactly "based on" any
existing type. But it will be a subtype of STANDARD-OBJECT.
On the other hand (given a bit of MOP) I can define new
types that aren't subtypes of STANDARD-OBJECT. They'll
still be subtypes of T, but if you think that's useful
then you should reconsider your opinion that Erik's
reply to you was a joke.

> > Next: I can't have arbitrary-length inhomogeneous lists
> > any more.
>
> I don't see the problem with allowing arbitrary length, but having to use
> homogeneous lists... yeah, that could be inconvenient. Trying to re-add
> them would just make the language more complicated (like Java).

In a H-M-ish type system, it's easy to allow arbitrary-length
homogeneous lists (a list-of-X is either a special object
called the empty-list-of-X, or (cons x y) where x is an X
and y is a list-of-X; with a bit of hackery you can make
all the empty lists the same) and easy to allow fixed-length
inhomogeneous lists (usually called tuples); it's combining
the two that you can't do. When you say "like Java", are you
thinking of something like casting to and from "object"?
Because then you get all those nasty evil wrong-type errors
that you presumably went static to avoid. I suppose they're
better localized.

> > Next: I can't do exploratory programming so well any more.
> > I can't take my running web server program and decide that
> > I need such-and-such a function to accept strings as well
> > as symbols, type in a new definition of that function,
> > and have everything just go on working.
>
> Right.

For me, that's a biggie.

> > Next: I have trouble imagining how CLOS is going to carry
> > on working.
>
> It won't. Next! ;-)

That's another biggie.

> > Does someone have
> > a design for a statically typed Lisp that wouldn't feel
> > really un-Lispy to work with? For instance, do you?
>
> Nope, just been toying with the idea.

My feeling is that if you want static typing, there are
plenty of good places to find it already. Why build it
into Lisp? The main things that make Lisp better than,
say, Haskell or O'Caml are things I'd expect you to have
to give up -- or at least to weaken considerably -- in
a "statically typed Lisp". So: What would a "statically
typed Lisp" have that Haskell and O'Caml don't have?

> > Erik Naggum observed that you can *already* consider CL
> > to be strongly, statically, implicitly typed, with everything
> > having type T.
>
> Still sounds like a joke. Implementing such a type system requires exactly
> 0 lines of code. Its requirements are necessarily met. It's like a type
> system that requires that objects are not of negative size.

Right. It's a joke. But it's a joke that makes an important
point. (This sort of thing is sometimes called "ha ha only
serious".)

> > So if you want to ask questions
> > about a "statically typed Lisp" then you ought to be more
> > specific about just how fine-grained you want that partition
> > to be, and why.
>
> Akin to Haskell. And...umm...because I feel like it? =)

If your only reason for doing it is "because I feel like it",
then all I can say is: go ahead and try it; see how it feels.
Rather you than me. 

-- 
Gareth McCaughan
.sig under construc

Relevant Pages

  • Re: How come Ada isnt more popular?
    ... are praising is, because what about trees of strings, trees of lists etc. ... A language with a Hinldey-Milner type system ... container varies, the element does not. ...
    (comp.lang.ada)
  • Re: Static typing, polymorphism, inheritance
    ... Actually Haskell has a type system which is cleaner. ... itn list and produces a pair of int lists. ...
    (comp.object)
  • Re: Source Code Wiki Start-Up Community
    ... migrating code-snippets and source code into it over the last few ... lists of pixels. ... newly-found pixels getting put on the second. ... a typical stack) will fail gracefully if it runs out of memory. ...
    (comp.programming)
  • Re: unexpected behaviour
    ... you are modifying the source code of your program! ... (defun my-eval (sexp) ... That means that you are modifying the function itself. ... which consists of data in the form of lists. ...
    (comp.lang.lisp)
  • handbook - kernel build question
    ... In section 9.3 of the handbook just before the two procedures it lists ... "If you are building a new kernel without updating the source code ... Are the words update and upgrade the ... we are free to abandon sin." ...
    (freebsd-questions)