Question for the Dylan fans here: gradual typing (of a kind) was one thing that attracted me to Dylan 20 years ago. How well does it hold up to newer forms of gradual typing?
Dylan never had “Gradual” typing, but some sort of optional, annotation-based typing.
Optional typing is a spectrum that ranges from simple type inference/recovery based on value use (implicit in many optimizing compilers for dynamic languages, Smalltalk and Cecil); to annotation-based type injection, which is what Dylan and Common Lisp have, although Dylan takes it more seriously; to Soft-typing, like the previous but with an actual formal type system, in some Schemes; to the new breed Gradual Typing which is much more advanced than all the previous. There are also some embedded dynamism in some static languages, allowing them run parts of code with little or no type annotation, often ranging from “clever” inference algorithms like Hindley-Damas-Milner, to ones that don’t require ANY annotation (take the type Dynamic as the TOP of the type-tree and just see it work; TAPL has a good chapter on this.)
Racket embeds a typed language in an “untyped” Scheme, using modules. But Gradual Typing is the most recent, and in my opinion most exciting evolution of hybrid typing, and I would love to see its further synthesis with modules, open-programming and distribution.
[Edit: Of course, I knew I wasn’t clever enough to have this opinion all on my own, I have internalized it from Siek’s and Taha’s epic “Gradual Typing for Functional Languages”
PDF: http://www.cs.colorado.edu/~siek/pubs/pubs/2006/siek06:_gradual.pdf ]
So what’s an example of something that Gradual Typing would allow us to do but that we can’t currently do in Dylan?
An interesting question. You’d probably be better served by getting an answer from Hannes Mehnert as he is our type system person, but he’s just returning from an extended (hacking) holiday. I’ll point him in this direction though and see if he has the time.
My answer would be that our weaknesses in the type system aren’t so much related to the gradual side of things as to the expressiveness of what our static type system can do. For example, a big weakness is that we can’t express a function type, just <function> rather than what the required signature is. (This is something we want to remedy.)
Hannes (the aforementioned) also wrote a paper and did an experimental implementation of some type system extensions: Extending Dylan’s type system for better type inference and error detection (pdf). This is linked from our publications page.
While writing the extensions to the type system, Hannes also created a visualizer for our optimizer that lets you see what the optimizer is doing to the control and data flow graphs. This is a huge aid in debugging and working on the optimizer and type inferencing. A video of this tool in an older incarnation can be seen here: http://opendylan.org/~hannes/test4.avi … He has re-implemented this tool’s backend pieces in master for the upcoming 2014.1 release. We’re working on making the client side of it more accessible.
We’d definitely welcome help on improving our type system and we’re building the tools to help make this an easier process.