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