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" <[EMAIL PROTECTED]>
To: "Claus Reinke" <[EMAIL PROTECTED]>
Cc: <haskell-prime@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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
"Computer science is no more about computers than astronomy is about
telescopes."
-- Edsger Dijkstra
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime
