Adding a DSEL library to the hierarchy

Conal Elliott conal at
Wed Nov 14 20:43:48 EST 2007

> Are there any strong opinions against creating a new ForSyDe root name?

I'd prefer more discussion about when to make new root names, when to wedge
things into the existing hierarchy, and when to create new root names, under
which to add projects (e.g. DSEL).

I often have trouble figuring out where to put things in the hierarchy.  For
instance, type classes cut across classifications like Data vs Control.
That cross-cutting is what makes them so powerful.  For TV, I made a new
"Interface" root name.  It overlaps with Graphics.UI but is more general.
For DeepArrow, I used Control.Arrow.DeepArrow, although it's not about
"control" (just as monads or arrows are not about control).

I have doubts about whether module hierarchy is workable in general.  Maybe
we could come up with something better.

  - Conal

On Nov 14, 2007 3:32 PM, Alfonso Acosta <alfonso.acosta at> wrote:

> Hi Bulat,
> On Nov 14, 2007 2:42 PM, Bulat Ziganshin <bulat.ziganshin at>
> wrote:
> > > 1) Use Language.ForSyDe
> >
> > for me seems most appropriate, unless you will invent some other root
> > for DSELs.
> Well, I Don't think there is such a demand for a DSEL root, so maybe
> Language would be appropiate.
> On the other hand, as Katil mentioned, ForSyDe is simply shorter.
> Are there any strong opinions against creating a new ForSyDe root name?
> > btw, isn't it better to rename lib into just Forsyde?
> > Mixed-case makes reading a bit difficult
> I guess I'll have to ask the original designers of ForSyDe. ForSyDe's
> name falls into the case of LaTeX so they might want to keep it
> unmodified, and besides, they are the ones paying for my work ;).
> _______________________________________________
> Libraries mailing list
> Libraries at
-------------- next part --------------
An HTML attachment was scrubbed...

More information about the Libraries mailing list