[racket] Typed Racket vs. Haskell

From: David Van Horn (dvanhorn at ccs.neu.edu)
Date: Tue Sep 18 17:14:58 EDT 2012

On 9/18/12 4:59 PM, Raoul Duke wrote:
>> No, by "types first" I think John and Vincent are talking about a conceptual
>> order.  I would phrase it a little more subtly: an ML (or Haskell)
>> programmer writes their types, then their programs (as you must); a TR
>> programmer thinks about their data, writes down a program, then writes down
>> the types (describing the data) they had in mind in the first place (and
>> often were written down as comments).
> i don't fully grok this but i'd guess there are other things going on as well.
> i'm not sure what you mean by "as you must" since ml/haskell have type
> inference.

Yes, but you can't infer the _definitions_ of types.  So what I meant 
was, you must define your types before writing programs.  In Racket, you 
can just think about a class of data (e.g. "all the numbers and 
strings") and write a program that operates on that data without having 
to first define the type that means either a number or a string.  If you 
want to come back to that program later and make a TR program by writing 
defining the type.

> i think it could be more that in non T Racket, you *cannot* use types
> to do the work, so you have to "manually" do it with predicates.
> whereas in typed languages, presumably you *want* to make use of the
> types, because then you are getting static checking e.g. that you've
> tested all constructors or whatever (not sure if/how that in
> particular would work in ml/haskell, but in e.g. haxe the switch will
> warn you if you miss a case).

I'm not sure what you mean.  You get a similar guarantee in TR.

#lang typed/racket
(: f ((U String Number) -> String))
(define (f a)
   (cond [(string? a) a]))

This doesn't type check because it's missing a case for numbers.


Posted on the users mailing list.