[Haskell-cafe] MPTCs and rigid variables
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?-)
More information about the Haskell-Cafe