George Russel wrote:
Graham Klyne wrote (snipped):
I like the principle of parameterizing Show to allow for different encoding environments...
I like the idea too, not just for Show but for any instances. It seems to me that in general you should be able to combine the convenience of the Haskell type system with the power of Standard ML's structures and functors.
That can be -- and has been -- done: http://www.haskell.org/pipermail/haskell/2004-August/014463.html The running example includes an ORD class -- which is like the Ord class but can be parameterized by a comparison function, so to speak. That is, there may be several ORD instances for one type -- e.g., several ways to compare integers. Also, we do not need to carry the discriminating label or dictionary all the time. Here's a snippet from the test in the above article:
let set1_empty = inst fs LR (undefined::Int) s1 = add 1 (add 0 set1_empty) rm1 = member 2 s1
set3_empty = inst fs LE (undefined::Int) s3 = add 1 (add 0 set3_empty) r3 = member 2 s3
we parameterize the applicative, translucent functor ORD->SET with two different integer-comparison functions, represented by labels LR and LE. More meaningful names are certainly possible. After we instantiated the functor, we do not need to mention the ORD parameter ever again. Ken Shan's paper, the above and the following messages http://www.haskell.org/pipermail/haskell/2004-September/014515.html argue that Haskell already has the full power of Standard ML's structures and functors (and not only generative but applicative functors as well).