
Taf - A plan for a statically-typed Lisp - swah
http://manuel.github.com/taf/doc/plan.html
======
samth
How will this compare to Typed Racket and Typed Clojure? In particular, Typed
Clojure works with Clojure's multi-methods, I believe.

Also, you should have a look at Andrew Wright's work on Soft Scheme, which
also used row polymorphism to statically analyze and check Scheme programs.

~~~
BruceM
There's also OpenDylan (<http://opendylan.org/>) and we're even considering
adding an s-expression syntax back as an alternative...

~~~
shaunxcode
does it currently - or are there plans to - compile to js?

~~~
BruceM
We'd love to do that. We just lack the manpower. There are a couple of
possible approaches ... one is a compiler backend similar to our C backend.
Another is to try out emscripten.

If you're interested in helping out, would love to chat. We're on #dylan on
freenode.

------
akurilin
Is there a philosophical reason why Lisp is generally dynamically typed, or is
it mostly an artifact of history?

Would anything of value of Lisp be lost beyond the typical trade-offs you see
mentioned in every static vs dynamic debate, such as up-front ease of
development?

~~~
rayiner
Lisp both predates static type systems, and has a philosophical bent towards
"late binding" to the maximum extent possible.

In terms of what you'd lose--eval() for one. It's only been relatively
recently that decent type inference has been integrated with interactive
execution (GHCi), but I think it's possible (though GHCi is still more limited
and cumbersome than full batch GHC).

~~~
dons
Eval is well understood in the context of static typing, since the early 90s
with Nilsson and Pfenning. So about 20 years now...

GHCi is a bytecode interpreter for Haskell, it supports the full Haskell+GHC
type system -- and has very little to do with eval() or your comment.

~~~
dons
Also, hbi, the first bytecode interpreter for full Haskell, is 23 years old
now...

There's no excuse anymore to be ignorant of "modern" static typing - a quarter
of a century is long enough.

~~~
akkartik
I found both your comments exceptionally useful until the last sentence.
There's plenty of excuse since it isn't being taught in undergrad computer
science courses, etc.

As one sample point, I have a PhD from a top-10 US institution. Partially in
compilers. I'm motivated everyday to learn about programming. I hack on
interpreters in my spare time. A lot. I am utterly 'ignorant of modern static
typing'. Setting aside modesty, I'll submit that it isn't my fault.

~~~
dons
Yeah, my comment is really more aimed at the schools that are teaching
language design as if it was 1971.

And you can always get a copy of TAPL,

    
    
          Types and Programming Languages
          Benjamin C. Pierce
          February 1, 2002
          ISBN-10: 0262162091
    

\---

And there's a typo above, Nilsson should be "Nielson", as in:

    
    
         "Flemming Nielson and Hanne Riis Nielson.
         Two-Level Functional Languages.
         Cambridge University Press, 1992.
    

The Pfenning paper I was thinking of was the S4 stuff:

    
    
        A Modal Analysis of Staged Computation
        Rowan Davies and Frank Pfenning, 1996

------
dschiptsov
The one of the biggest ideas behind a classic Lisp is now called Exploratory
Programming - a natural way of evolving your program very quickly.

When a programmer is forced to think about a type before he already decided
what it could be is a limiting factor. All scripting languages are based on
this idea.

And, of course, having lists of elements of just the same type and different
sets of functions for different types of, say, lists is an ugly thing.

The current mass-hysteria about necessity of static typing is due some sort of
Bandwagon effect.

I think it is much better to learn the elegant approach of authors of Scheme
and other Lisps to hide necessary hardware types inside a runtime and to allow
programmers and themselves to think in terms of a problem domain.

So, statically typed Lisp is something like four-wheel bicycle. It is very
"safe" and "stable" but for some reasons no one wants it.

~~~
sbt
I agree that it's important to retain the dynamism of LISP, but if types could
be made optional, it could be useful. In my view, the expressive power of LISP
is the same thing that hinders it for use in teams (unless the team is small
and super qualified) and consequently what has prevented its widespread
adoption.

I think this is a wonderful initiative. I originally tried to do this a few
years ago, but gave up after having considered the implementation too involved
(I was using LLVM at the time and was effectively writing a compiler). I still
think an optionally typed LISP compiler would be a great idea if somebody is
willing to do it.

EDIT: grammar.

~~~
yvdriess
CL has optional types and quite an interesting type system. Check out Qi if
you want a Lisp designed to have a rich type system.

~~~
markokocic
Shen is the new version of Qi. Qi is not developed anymore.

------
DanWaterworth
> Taf is not properly tail recursive.

I don't understand why tail recursion isn't a bigger deal to people.

~~~
pjmlp
Maybe because many still avoid recursion like hell?

------
jjtheblunt
Common Lisp has optional type annotations; doing so should only help the
compiler (or the interpreter if you're running that way).

Paragraph 4 of <http://en.wikipedia.org/wiki/Common_Lisp> for a vague
citation.

~~~
rayiner
Common Lisp's optional type annotations aren't complete. That is to say there
is no level of annotation you can provide that guarantees you won't get type
errors at runtime.

------
turnersr
How will this compare to Shen ( <http://www.shenlanguage.org/> )? In my
experience it has a more expressive type system than Taf.

------
groovy2shoes
Neat! Is anyone aware of any accessible introductions to the concept of row
polymorphism?

~~~
evincarofautumn
<http://lambda-the-ultimate.org/node/4666>

~~~
groovy2shoes
Thanks! I read the MLPolyR paper when it was posted on LtU, but I found it a
bit hard to digest, and the link to your article is also purple so I guess I
read it at some point :)

------
batgaijin
I think strongly static typing can be added to CL, if I understand this paper
correctly: ftp://ftp.cs.utexas.edu/pub/boyer/diss/akers.pdf

------
justin_vanw
Lets take a language that is already marginalized, and remove one of it's best
loved features! That'll get 'em excited.

