On Mon, 1 May 2000, Tom Pledger wrote:
>
> Here's an example of something which could be done, without major
> language extensions: insert a partial ordering class between Eq and
> Ord. (It's something I've advocated before, so I won't dwell on it
> this time.)
That's why some sort of a big picture might hopefully
help to clearly organize the process into several stages
of the iteration loop:
+ What extra features would be really desired and, first of
all - WHY? How will it make Haskell more useful
from math-oriented application perspective? Opinions will
differ, I am sure, but some small common subset could be
probably accepted by most at first iteration.
+ How to implement them? What strategies are feasible?
What seems to be happening now is some sort of
sporadic voting on Basic Algebra Proposal as a whole:
"I like it", "I dislike it", "I agree with part of it", etc.
Some opinions has been expressed but nothing visible
constructive is coming out of the current process.
I think this happens because the Proposal is quite
specific and mixes Sergey's point of view on
some implementation issues and his naming convention
with generic goals and needs. A recurring comment
is that a particular feature should not be implemented
as class, but datatype, etc.
If I could suggest to Sergey, or anyone else who
feels competent in doing so:
+ Start with a big picture and forget details
for a moment.
Use standard naming convention from Mathematics
Subject Classification, so we all could refer
to it, check it, and compare notes. Graphic
representation would be nice.
+ Justify the needs for all those elements
from the big picture. What am I buying
from this as a whole and why I need this
particular structure? What can I do with it?
[That's why I cited Tegmar's diagram yesterday:
he evidently knew where he was heading]
The bottom line is that some convincing
arguments for changes are needed first before
implementers are to be bothered at all.
Jan
