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.
Manuel Simoni's blog about programming (languages).
Very interesting.
ReplyDeleteWhat 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.
Take a look at Typed Racket.
ReplyDeleteIt's certainly much easier if you design your language with static type-checking in mind.
Isn't Lisp pervasively mutable? Do you have any constraints to reason about the monotonicity (or lack thereof) for type decisions?
ReplyDeleteIt 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.
ReplyDeleteInitially, 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.
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.
ReplyDeleteBut, can you reconcile static typing with fexprs? :-)
ReplyDeleteI 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.