Class System current status

[Henrik Nilsson]

Hi all,

Stephanie wrote:

 > So it looks like we're stuck at pretty much the same proposals for the
 > class system.
 >
 > a) standardize on MPTC and FDs using rules from CHR paper.
 > b) don't standardize anything, and wait for ATs to take over
 > c) punt---standardize the library and exact form of FD for that
 >    library, but no more, or map out some longer timeline for this
 >    issue.

For what it's worth, I think b) would be very unfortunate,
unless we end up in the even more unfortunate situation
of the Haskell' process stalling, so that ATs have taken
over by the time we're done.

 > For a while I thought (a) was the clear choice. The theory has been
 > worked out, we have a lot of experience using them, and key libraries
 > depend on them.

That's what it seemed like to me too.
But admittedly mainly from a spectator position.

 > However, not everyone is convinced by (a) because of  the fear of too
 > early standardization. We may end up with a lot of code that uses a
 > feature that will eventually be deprecated.  There are perhaps three
 > counterarguments to this point of view:
 >
 > - We're already in that state. There *is* a lot of Haskell code that
 >   uses FDs, it's just not Haskell 98 code. Whenever ATs take over,
 >   we'll still have to deal with this code.
 >
 > - It may be that all uses of MPTCs/FDs may be subsumed by ATs, and in
 >   fact there is (or will be) some automatic way of translating FD code
 >   to AT code.
 >
 > - It may not be all bad for a future Haskell standard to include both
 >   ATs and FDs. Certainly more complicated, but I haven't seen any
 >   evidence that these features interfere with eachother.
 >
 >  Are there any merits to these counterarguments?

There's certainly merit to the first, and likely to the second too,
from what I've seen. (Don't know about the third: as a matter of
principle, I don't like a situation with two (or more) similar
language features essentially addressing the same need.)

Here's another argument along the lines of the first two. If MPTCs and
some form of FDs/ATs are not standardized, people who want to comply
with the  standard will in many cases have to resort to cumbersome
workarounds (loss of abstraction and hence effectively lots of code
duplication).

Migrating such code to use MPTCs and FDs/ATs is likely going to be
a lot more work than, say, migrating code that uses FDs to use ATs
instead, or migrating it to use some slightly different version of
either. Indeed, this task might well be automatable.

And why would one want to migrate such code once MPTCs/ATs get
standardized? Well, if nothing else, to make it more maintainable,
and for libraries to make them work smoothly in the new setting.

The other thing that could happen, of course, is that people simply
stick with GHC and ignore the standard. And then a lot of the
Haskell' effort would have been in vain.

Bottom line: At this point I am not overly worried about too
early standardization for MPTCs + FDs (or whatever). I am
worried about the no-standardization option.

If someone has really good arguments for why early standardization
is likely to create a legacy nightmare, while no standardization
wouldn't, please speak up!

Best,

/Henrik

-- 
Henrik Nilsson
School of Computer Science and Information Technology
The University of Nottingham
nhn at cs.nott.ac.uk


This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.