[MLton] List comprehensions?

[Wesley W. Terpstra]

On May 30, 2007, at 8:18 PM, Vesa Karvonen wrote:
>> Speaking of which, my SML++ shopping list would also include:
>>    active patterns (see F#)
>
> Have you looked at Rossberg's HaMLet S:
> http://www.ps.uni-sb.de/hamlet/#successor-ml .  It has two designs for
> views.  BTW, you can try HaMLet S (through smlbot) on the #sml irc
> channel on freenode.net.

Nice! Views are definitely an acceptable alternative to active  
patterns. :-)
Most of the other improvements he lists also seem like things that  
should already be in SML!

The only feature I don't think I'd use is the 'do declaration'.

So many of the new features address problems I've had with SML, that  
I'd be tempted to switch if MLton weren't so darned fast. :-)

I didn't really understand the 'first-class modules' or 'higher-order  
functor' additions.

This feature will probably break MLton's defunctorization, though:
> * Local Modules.
>
>   Structure, functor and signature declarations are allowed in  
> local scope:
>
>     fun sortWithoutDups compare =
>         let
>           structure Set = MkSet(type t = string; val compare =  
> compare)
>         in
>           Set.toList o foldr Set.insert Set.empty
>         end
I have needed this feature in the past, but what does this mean for  
'val's declared in the functor? Must they be evaluated every time the  
function is called? I think so. They might depend on the parameter.

>>    type classes
>
> I heard that some people are working on this and related stuff.  So,
> you might eventually get what you wish for.  :-)

I think that the equality type is an ugly wart in SML. Plus, haskell  
shows just how flexible type classes can be. In particular, the a..b  
notation in Haskell is an elegant example of how great type classes  
are. Similarly, the List.map, Vector.map, ... show redundancy that so  
cleanly fits this paradigm that it's almost embarrassing it's absent.