Comment by rurban | Hacker News Reader

Comment by rurban | Hacker News Reader

Parent Full thread

Types are supported since the 80ies, with (the) and optional declarations. Almost nobody uses them. Well, CL says: types are always carried around in every value, so we do have types, and we are always type-safe. Which is a proper point.

Then SBCL has superior internal type support in its python compiler, leading to many optimizations. It creates specialized copies of typed methods, and has a nice optimizer framework to deal with that.

Felleisen (Typed Racket) seems to hate types, he summarizes it with types make racket slower, not faster. But he is still developing the only seriously typed scheme effort. Forgot about Stalin, but if I remember correctly it was similar to the CMUCL/python type optimizer.

In my dynamic language I've implemented gradual typing with great success (cperl): more precise, producing better specialized code, faster, detecting more errors at compile-time and better documentation, so I'm sceptical why Felleisen has so many problems. But I implemented it with performance in mind (premature optimization and such), not completeness. Typed php seems also to go well, also the various JavaScript variants. Just scheme, python and ruby not so.

In my experience Typed Racket programs are never slower than their dynamically typed Racket equivalents. Sometimes they are faster (such as when the program does a lot of numeric computation).

What _can_ be slower is a _mix_ of TR and R. Because TR protects the boundary between the two with runtime contracts. Because it wants safety/soundness.

I'm not any kind of gradual typing expert, but, it seems like you could calibrate speed vs. soundness for boundaries in different ways. TR has prioritized soundness but it seems like you prefer speed.

Well, I do have the same problems between unchecked and checked expressions. You get the speed only with series of checked expressions, but you have to cast to any/dynamic/cons boxed type on each boundary. This is the major slowdown. When the series of expressions is too short, no transformation to native should be done, because the casting and conversion back and forth is more expensive than the win by using the specialized ops.

Similarily SBCL/CMUCL has the similar problem with polymorphic explosion of generating too many methods, which are rarely used. Javascript V8 and friends solved that better.

My speed comes from avoiding consing, my native types are bitfields. Lisp types are usually a class pointer for every cons cell. For me certain casts are permitted, which are not permitted with Typed Racket. So yes, I have to permit traditional code which worked before, esp. with inferred types from literals. Racket has the advantage of defining stricter language subsets, which we only have with Perl 6 also. There you can override even language and type semantics.

Chez has a nice tagging scheme, which should speed up Racket a lot.

Several gradually typed languages don't infer from literals, but that's one of the best speed gains. E.g. the literal 1000 is a union of int32, int64, uint32 and uint64, all possible valid integer types for a certain value. A negative number cannot be unsigned, and a too large number cannot be 32bit. Problem is that people rarely add types, you need to infer 90% of them.

Typed Racket is more ambitious than other attempts at adding types to an underlying untyped language. Namely, Typed Racket guarantees that typed code is never to blame for certain contract violations, and, if any such contract violation happens, it will be properly traced back to an offending piece of untyped code. This is what makes gradual types gradual (as opposed to merely optional), alas, it is also what has been found to have unacceptable overhead.

Relevant paper and talk:

http://www.ccis.northeastern.edu/home/types/publications/gra...

https://www.youtube.com/watch?v=1u1JGwmW0IQ

I think this is the correct video link.

https://www.youtube.com/watch?v=5DlEj6daNEo

Oops, sorry, yes.

Reply on news.ycombinator.com