hi, On Thu, 15 Apr 2004, Wolfgang Thaller wrote:
I think I'm reluctant to accept Dessy as "the" collection framework mainly because you're trying to sell a big package of many changes at the same time
Actually I tried to make clear in the documentation, that you just _don't_ have to accept all the changes at the same time. Expecially, no language changes are obligated, since you can already run it now, in plain old Haskell98 with MPTC. In fact a try to offer at the same time: - a future-combatible approach, ensuring that we don't have to redo it from scratch when we want to add another feature. - a migration path from the present to the future, with the option to fully design the future on the way (e.g. things like the underscores can of course be changed). Let's untangle the aspects:
1) a hierarchy of Collection classes, based on MPTC without FunDeps
The proposed interface standard is independent from implementations (although I tried of course to make many sensible implementations possible).
People aren't quite done arguing whether the collection classes should rather use fundeps, or whether we should have a single-parameter Sequence class, etc.
I think that the argumentation has stopped without finding a solution. The recent proposals (Ross and me) provide new strong arguments. Ordered Structures without MPTC are impossible to do in a practical way (my conjecture, awaiting refutation), so we don't really have a choice. For FunDeps we have the choice and for the moment it is good to know that we can quite well do without. It is to be shown whether we can do better with FunDeps, but then the addition is possible in a compatible way. Sequences can be done without MPTC, but not in the same hierarchy as the Ordered Structures. (Again, my conjecture, the argument is that the implmentation of an Ordered Structure will need an Ord context already when becoming instance of Collection. Like this: instance ( ... Ord a ... ) => Collection SomeSet where (Well, it would work if we didn't use Constructure Classes and use FunDeps, does perhaps anyone want to rewrite the library to check that approach...?))
2) Implementations to go along with it
Actually I reserve the name "Dessy" for the implementations. And due to their special design goals, they are certainly not sufficent for all uses, maybe they shouldn't even be the default in the future.
3) Lots of "propaganda" against lists and a proposal to change the language to remove it's bias towards lists
4) A "Stream" type whose only purpose seems to be to avoid using list syntax when the semantics of singly-linked lists are required
At the moment, these facilities allow users of Collections in a list-less way, which is also combatible with a possible future "list-less Haskell". Of course, "list-less Haskell" is not for today or tomorrow, but it is a vision that one can keep in mind. But again, you needn't buy that vision to use the Collections standard or my implementation.
5) Some obvious naming changes like head --> first
It is not the only truth to dub this a "naming change", since the new functions are quite different (since much more general) from the traditional ones. When speaking of [] lists I still think, it's appropriate to use head, tail, and so on. (Just that I don't think, one should use [] lists in new programs.)
Number 5 definitely makes sense (although I haven't had a look at all of your names yet). It will be painful, though, and there will definitely be many people who just write modules with declarations like "head xs = first xs".
[underscores are better]
What psychological studies?
I need some time to find the references. This gives you a chance to find the studies proving the contrary.
Mhm. We seem to have a small clash of cultures here. Down here in old-fashioned Austria, calling somebody's opinion both absurd and ridiculous in the same sentence is sometimes considered equivalent to a personal insult.
Well, I didn't say that someone's opinion is absurd. Here is a more careful wording of my (still personal and very emotional) belief: "From a viewpoint of abstraction, ignoring all the historic achievments of LISP and its successor languages, the insymmetry of performance of list operations is absurd, and the inconsistent function names are ridiculous." Of course the traditional names are sensible if one knows their history. And of course lists used as streams are important in many applications. But I think anyone that wants to transpose the traditional name and semantics of lists to Abstract Collections has just not thought long enough about it.
Sorry for complaining about this, I know I shouldn't be that narrow-minded...
You aren't. Yet. Haha! Robert