DData in hierarchical libraries

Daan Leijen daanleijen at xs4all.nl
Mon Feb 23 21:08:15 EST 2004


JP Bernardy wrote:
> Then, I would propose a complete revised code, unless
> Daan wishes to do so.

It would be great if you can integrate the
library in fptools -- just keep my name in the source code.

I think though that it would be best if you first
create a package with your proposal for review before adding
it to fptools. Furthermore, we should add a proper BSD style
license to all the sources. I have a specific license which
I will send to you that should be attached, as I have agreed
this license upon some (undisclosed) companies that are using
the DData library.

Here are detailed comments to your proposal:

> * remove the Scc module
>
>  Seems to be redundant with SCC in Data.Graph

Not quite, it abstracts over the "Int" used to designate
nodes and it returns the nodes in a very well specified
order. I agree with you though that it is a rather strange
module in the whole of DData and that it may be better to
remove it.

> * foldL, foldR, foldI -> foldl, foldr, foldi
>
>  to match Prelude.fold[lr]

The drawback of this is of course that you get even
more name clashes with the prelude... requiring a
"import Prelude" clause or "hiding (foldr, ...)" clause...

Maybe it is better for the user to say "foldr = foldR" if
they don't want to qualify their names?

> remove find, favouring (!) and lookup.

What do you mean by this?


> * rename "single" to "singleton"

Good plan, although I am in favor of adding "singleton"
and marking "single" as deprecated in the documents.
(so my old code can at least compile)


> remove (Queue, Seq).append (favouring "<>")

I do not like this. I would rather vote for removing the
operator. "append" is absolutely clear, while "<>" doesn't mean
anything for the naive reader. That is why all my operators
are also implemented by an explicit function.

> >map (append q1) listOfQueues
>
> means that q1 is "prepended" to each queue.

Well, you can also write "map (q1 `append`) listOfQueues"  :-)


> * Rename subset & friends.

Good plan. Lets go for "isSubsetOf" or something.


> * Make maps look more like collections of couples.

What !?! Why would you like to do that? It goes totally
against the spirit of Haskell.


> * rename (<>) to (++)
> * Make some types instances of Ord and Functor.

Maybe it is a good idea to make more data structures
instances of Functor, Monad, and MonadPlus. Or maybe the
proposed Monoid etc. Note that operations like "fmap" don't make
sense for Set's as the type is more constraint, i.e.:

> Set.map :: (a -> a) -> Set a -> Set a

This gives you the required behaviour, like "mappend" for
concatenation. Things like (++)  were specifically reserved for lists
by the Haskell98 committee -- regardless whether you like it, I think
we should stick with that philosophy.

All the best,
  Daan.



More information about the Libraries mailing list