Monday, January 14, 2013

Current project

In my quest for a good Lisp, I could no longer ignore static types.

See Taf - A plan for a statically-typed Lisp.

There shouldn't be any difficult roadblocks, so I expect a release sometime in or before summer.


Mariano Montone said...

Very interesting.

What do you think about a statically typed Common Lisp? I'd love to see something like that, probably plugglable types, changing the underlying language as slightly as possible.

Do you think that would be viable? I don't know much about these matters.

Manuel Simoni said...

Take a look at Typed Racket.

It's certainly much easier if you design your language with static type-checking in mind.

dmbarbour said...

Isn't Lisp pervasively mutable? Do you have any constraints to reason about the monotonicity (or lack thereof) for type decisions?

Manuel Simoni said...

It will be a bit less mutable than other Lisps, yes. E.g. if a function is defined as int -> int, you won't be able to redefine it as int -> bool.

Initially, type-checking will also be whole-program. If you enter a new line at the REPL, you'll have to re-check the whole program with this new line added.

Manuel Simoni said...

In the generated MLPolyR code that is then used for type-checking, cells are introduced so the Lisp top-level scope semantics can be maintained - the Lisp top-level is basically a letrec* whereas ML offers let* for groups of values and letrec for groups of functions.

John Shutt said...

But, can you reconcile static typing with fexprs? :-)

I gather you're having, ah, fun implementing hygienic macros.  I didn't get them at all till I implemented them as part of my dissertation section 6.4.