sequences

[Robert Will]

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