[racket] thank you for typed racket
11 hours ago, Matthias Felleisen wrote:
>
> As is, it is almost a two-edged compliment. A mean-spirited MLer or
> Haskeller -- not that there are any -- would and should reply with
> "told you so. You should have used ML or Haskell and you would have
> been even more productive."
I think that the way my class language evolved separates nicely the
three things that you indirectly refer to:
1. The compiler code advantage: I had this well before TR (TS,
actually) in the form of a `define-type' that is even more ML-ish
than the one used in EoPL/PLAI. The advantage was very obvious,
and clearly in the domain of the above "told you so".
2. The typed language advantage came later when TS materialized, and
the benefits were also expected -- very useful, but overall a
smaller step than the first (probably due to the material). This
is an even worse demonstration of "told you so". (That was
expected because I had already been using type declarations in
comments that were very precise. Enough that the switch to TS was
mainly an automatic transformation of ";; ...type..." lines to "(:
...type...)" lines.)
3. Then there are the unique TR advantages. The two most obvious
things are subtypes and occurrence typing. The combination of
these mean that I can still get the advantages of the dynamically
typed language *without* losing any of the static typing benefits.
I do many small modifications to the language that diverge from the
"main" line of interpreters -- if this was using ML or Haskell, the
cost of these diverges would be much higher since each would come
with a considerable overhead of additional type definitions etc.
To give a concrete example for such a diverge, one variant of our
interpreter demonstrates a "more meta-circular" interpreter that
represents numbers and functions using racket numbers and
functions, something that is probably unimaginable with an HM
language.
As for a wish list:
* I wish that I could write more real code for types.
* I wish that TR would have some built-in notion of a disjoint sum
type so I could remove my `define-type' and `cases' and switch to
using just `match'.
* I wish that the whole thing with defining a new type based on a
predicate (I don't remember the name -- that thing with preventing
string injection attacks) would be easy enough that I could use it
in class. (Last time I asked I was told that it's not there yet.)
* And of course I wish that compilation would be much faster.
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!