alternative translation of type classes to CHR(was:relaxedinstance rules spec)

[Claus Reinke]

Thanks, Taral,

it is good to know that I'm not just writing for the archives!-)

a paper, yes, at some point (unless someone shoots a hole in my
suggestions first;), but at the moment, I'm more concerned with
keeping my hopes for Haskell' alive, and completing my case. 

when Haskell' was announced, most of us thought that the committee 
would just collect all those old and proven extensions like MPTC, 
FDs, overlapping instances, undecidable instances, more flexible 
instances, etc., figure out the common story behind them and weave 
all of that into a coherent new standard, leaving the newer extensions 
like GADTs, ATS, etc. for future standards. unfortunately, the idea 
that well-established popular extensions implied well-defined 
behaviour turned out to be an illusion, so unless we're doing the 
work now, we're not going to have the useful standard we wanted.

which makes it all the more important to have genuine discussions
here - there are so many extensions that have been proposed and
partially implemented over the years since Haskell 98, for which 
noone is even bothering to speak up on this list (generics in their
various forms and implementations? better support for faking 
dependent types? template meta-programming? a genuine type 
Dynamic, as in Clean? ..). I am a bit worried that many 
Haskellers appear to have given up listening here, let alone 
arguing for their interests. and with the extreme timeline the 
committee is insisting on, there just wont be time to wait for
the first draft and start complaining then.

I can't argue for all the features I'm missing in the discussions so
far, but I can try to help with a few of them, and hope that others
will wake up before the committee closes the doors.

you ask about effects on existing handling of FDs: I appreciate the 
work that has gone into FD-CHR, and into the refined conditions 
now implemented in GHC head, but I cannot accept them as the 
last word (for reasons explained in previous emails, the restrictions 
are too restrictive in practice, for real programs; eg. since the 
change, I suddenly have to use "undecidable" instances for 
instances that are obviously decidable, which kind of defeats the
purpose of that flag; as a minimum benchmark, I'd like to be
able to use the Data.Record.hs stuff, in its simple form, without
the hacks, in whatever Haskell' turns out to be - and currently,
we are far from passing that criterium). 

I hope I have now explained what I meant when I said that most 
of the confluence issues were due to the translation, not inherent 
in FDs, and I intend to use this groundwork for tackling the 
combination of FDs and overlap resolution, in the way explained 
informally in my early emails here. I also hope that this simpler 
basis might help implementors to simplify and gain more confidence
in their code bases (in which these features have grown over years,
in wild combinations with other experiments, often driven only by 
examples and counter-examples).

unfortunately, tracking down the reasons for why these conditions 
were considered necessary in this form has been a slow process, 
as has been trying to show that they might not be. so it really helps 
to know that I'm not the only one who expects more from Haskell'.

having the formal specification in the FD-CHR paper, and having 
some of it implemented in GHC, is one of the best examples of the 
Haskell' process actually producing useful deliverables, and could
set the example for the other aspects of Haskell'. so I can only 
encourage Haskellers to read the paper, and to try GHC head,
and see whether they can live with the suggested limitations and
formalizations. if not, raise your voice here, now!

cheers,
claus

----- Original Message ----- 
From: "Taral" <taralx at gmail.com>
To: "Claus Reinke" <claus.reinke at talk21.com>
Cc: <haskell-prime at haskell.org>
Sent: Monday, March 13, 2006 10:57 PM
Subject: Re: alternative translation of type classes to CHR(was:relaxedinstance rules spec)


On 3/13/06, Claus Reinke <claus.reinke at talk21.com> wrote:
> [still talking to myself..?]

This is all wonderful stuff! Are you perhaps planning to put it all
together into a paper?

What effect do you think this can have on existing algorithms to resolve FDs?

--
Taral <taralx at gmail.com>
"Computer science is no more about computers than astronomy is about
telescopes."
    -- Edsger Dijkstra