In all honesty what I want is a solution to the problems clearly outlined in the first two sections of his proposal. People may not be clamouring for this (yet), but that maybe simply because they've gotten used to the de facto Haskell style of giant type classes and never seriously asking themselves if maybe there was a better way to do things. Certainly the issues that 1) Num needs broken up, and 2) Functor and Monad should be related, do come up relatively frequently.

John's example for 'Lattice' is really spot-on, that is exactly what
1) a developer for an advanced class wants
2) exactly what a developer would like to provide to users (ie the coarser Lattice and BoundedLattice).

In my mind that defines the problem to be solved quite nicely. Which gets us to:

Simon Peyton-Jones wrote:
I've just had another look, which threw up quite a few questions in my mind.   
I wonder what would be a good list to discuss it.  Maybe this one is not bad, 
because it has people interested in Haskell innovation, regardless of whether 
it's a live Haskell' candidate?
I wrote the above because there really are two very different kinds of questions: requirements and design. If there is first a solid agreement on requirements, then it is much simpler to tweak the design. [Motherhood stuff, sorry, but sometimes a reminder of such things is useful]. So in what class are your questions?

Since we are talking requirements: to properly follow Parnas' ideas on good design, we should ask ourselves what are the likely future changes in this area. I know of one extension which will definitely be wanted in the future: renamings. For example, mathematicians frequently switch between additive and multiplicative notations for Groups. So one would want to ``inherit'' from a class but allow for a name change at the same time. In effect, one can already to this, ie
class Foo a where
   foo :: a
class Foo a => Bar a where
 bar :: a
 bar = foo
However the difference is that the equility bar = foo is not known intensionally, ie not available to the compiler as something that can be reasoned with. I do believe that that will be an important future consideration. [I could be wrong about how the status of such equalities in the language definition, but I must admit I would be surprised if it were otherwise]. Note that such 'renamings' are a common operation available in "algebraic specification languages" of various kinds. And type classes really are much closer to (algebraic) specifications than anything else, so I do believe that one can learn what are the 'useful operations' from those languages.

Proper design then means that a current solution allows for a solution of the above in the future, and definitely does not make such a solution impossible. The solution does not have to be done (either designed, much less implemented) now. [Teaching SE does seem to infect one's mind, doesn't it?]

Jacques

_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Reply via email to