Manuel Chakravarty, a computer science professor at UNSW, publishes papers on Haskell, GPU programming, type systems, and teaching functional programming.
HN commenters link his papers page to establish his standing in the field, noting he made Haskell for Mac and is an old timer.
> My point with this arguments is not that "polymorphic instances" are as powerful as functors (they aren't!). Rather in this (and similar examples) it's higher-kinded types vs modules, no type classes involved.
This paper disagrees: http://www.cse.unsw.edu.au/~chak/papers/modules-classes.pdf . See below.
> The Haskell equivalent is just a plane[sic] function, not a polymorphic instance, and there is things that can be done in the term language but not the module language.
A plain function can't return fresh new types. A functor can.
> SML/OCaml with higher-kinded types would annihilate this argument
As I said above, OCaml's higher-order modules let you encode arbitrarily higher-kinded types. Even if OCaml didn't have parametric polymorphism in the core language, you can express it in the module language with applicative functors (although the result would be a lot more verbose). If you don't believe me, give me an arbitrary higher-kinded type, and I'll tell you how to encode it in OCaml.
No, I haven't, but does it add more to ML than a bunch of syntax changes? It looks like an attempt to make ML more palatable to programmers familiar with C and Java. I skimmed the docs on that site and saw that it does have ML-style modules and functors, but does it also include something like typeclasses? I thought combining the two was still almost an open research question, although tbh I haven't slogged through this paper yet: http://www.cse.unsw.edu.au/~chak/papers/modules-classes.pdf
To be completely honest, I'm a little skeptical given that the first page in the "Mythryl for SML programmers" highlights adding special-cases to the front-end to support printf: http://www.mythryl.org/my-Mythryl_printf.html I don't really miss printf in SML, although if I wanted it I think I would rather reach for this kind of type hackery instead: http://mlton.org/Printf
It's too easy to tease, but I will try to resist.
But, seriously, they've been talking about this GPU work for upwards of a 1.5 years now. Usually we get something to play with, even if it's pretty badly broken (I'm thinking NDP here), so the lack of code here is pretty atypical. The accelerate link above is news to me, though, so that's helpful. Hope to see more soon!
* EDIT (to back up my 1.5 years claim):
earliest mention, May 15, 2008:
http://www.cs.chalmers.se/Cs/Grundutb/Kurser/svh/Slides/may-15-2008-Obsidian-shortp2.pdf
Chak's own work, Jan 10, 2009:
http://www.citeulike.org/user/iff/article/3872848
http://www.cse.unsw.edu.au/~chak/papers/LCGK09.html
and, of course, accelerate ("reference implementation") was only released Aug 17, 2009:
http://hackage.haskell.org/package/accelerate
I have ~4 years experience writing OCaml, and ~1 year experience writing Standard ML. I also once did contracting for a Play app in Scala for 3 months. A month ago, I started looking into Haskell for the first time for another side project and was immediately able to pick it up due to how similar it is to OCaml and Standard ML. In particular, the type syntax and function declarations are similar; understanding monads in SML/OCaml helps understand... everything in Haskell; and understanding of modules/functors/signatures transfers indirectly to type classes as well. (Here is a paper going into even more detail [0].) It felt like Haskell has some of the syntactic sugar I always wished Standard ML had as I learned its limitations.
[0] http://www.cse.unsw.edu.au/~chak/papers/modules-classes.pdf
I think we're going to see some clever optimizing DSLs (a la FFTW) -- restricted languages for the kinds of embedded programs you write on such an architecture will be easier to optimize than general purpose languages. Particularly if they have a clear cost model.
The Haskell embedding is very likely to head in that direction.
(See e.g. in this style : http://www.fftw.org/faq/section4.html#whyfast or this style : http://www.cse.unsw.edu.au/~chak/papers/polymer.pdf -- code generation + DSL + constraint solver for instruction level timings).
At least, that's what I'd do.
The more important question of whether or not systems like C++ and X-Windows cause actual permanent brain damage in humans, will have to wait for the autopsies of human brain doners. That won't be soon, since they're still only in the animal experimentation stages. But I think it's reprehensible how they're exposing all those poor innocent bunnies to shoddy static class libraries without garbage collection, and high doses of raw Motif.
http://www.cse.unsw.edu.au/~chak/quotations.html