[racket] thank you for typed racket

From: Eli Barzilay (eli at barzilay.org)
Date: Tue Feb 22 20:48:41 EST 2011

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

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!

Posted on the users mailing list.