[Haskell-cafe] MPTCs and rigid variables

Claus Reinke claus.reinke at talk21.com
Tue Mar 6 19:39:16 EST 2007


>> ps. i was somewhat shocked to read that SPJ wants FDs gone.
> 
> Why?  Simon has good taste. :)

de gustibus non est disputandum ;)

FD have uses and problems and AT have uses and problems. starting anew 
with the latter doesn't fix the problems, it just changes their form.

if AT are meant to take over from FD, then either they have fewer uses or 
similar problems. the assumption seems to be that AT are somehow equivalent 
to FD, as in "any working FD program has an equivalent AT form". 

but if the problems can be fixed in the AT form, they can be fixed in the FD 
form, and if the problems cannot be fixed in the FD form, they cannot be fixed 
in the AT form. in particular, many of the problems with FD are ambiguities in
interpreting interactions with other popular features, such as overlap resolution.
it took half a decade of practical experience to expose such issues for FD, and 
i don't see the fact that AT haven't reached that stage yet as any advantage.

there are examples for which the AT form looks nicer than the FD form,
and there are examples for which the AT form is more complicated than
the FD form. about the only half-way convincing non-aesthetic argument
i recall in favour of AT is that their restricted form might help to exclude 
problematic programs, but if that is true, imposing equivalent restrictions 
on FD should have similar benefits. 

i was hoping that the delay on standardising FD meant that we would get
an additional option, with opportunities to gain insights into the issues with
AT, without losing the FD view. after that, the issues common to both FD 
and AT ought to be sorted out. only *after* that would there be any point 
in chosing one of the two on aestethic grounds, and possibly phasing out 
support for the other.

unless i'm missing something, and all this has already happened?-)

claus



More information about the Haskell-Cafe mailing list