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 wrote:

Hi Bulat,

On Nov 14, 2007 2:42 PM, Bulat Ziganshin 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@haskell.org http://www.haskell.org/mailman/listinfo/libraries

"Conal Elliott" writes:

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 belive the primary - and perhaps only justifiable - purpose of the hierarchy is to avoid namespace collisions. A new root is a good choice when you have a library that has a distinct name (like "ForSyDe", or, for that matter "Parsec"), and includes cross-hierarchy functionality.

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

Here's an essay about categorizing stuff: http://www.shirky.com/writings/ontology_overrated.html The short version is that any hierarchy is going to have problems, and nobody (except in the physical world) is browsing a hierarchy anyway, they just enter terms in search fields. So a wide/shallow hierarchy incurs no additional cost, and reduces at least some of the problems compared to a narrow/deep one. -k -- If I haven't seen further, it is by standing in the footprints of giants

On Wed, Nov 14, 2007 at 02:45:23PM +0100, Ketil Malde wrote:

"Alfonso Acosta" writes:

...

My options are: 3) Use our own root name: "ForSyDe". That's how it's currently implemented, but I guess that one of the purposes of having a namespace extension was precisely to avoid people adding their own root names.

It's what I do, too. Frankly, I don't see any problem with this, and if I had a penny for every time I had to type D a t a . B y t e S t r i n g . L a z y . C h a r 8 or T e x t . P a r s e r C o m b i n a t o r s . P a r s e c in ghci just to disambiguate some operation... Does that mean I'm not the only one longing for

:m +Data.ByteString.Lazy.Char8 as B In that case I should probably submit a feature request for it. Greetings, Remi

-k -- If I haven't seen further, it is by standing in the footprints of giants _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

...

It's what I do, too. Frankly, I don't see any problem with this, and if I had a penny for every time I had to type D a t a . B y t e S t r i n g . L a z y . C h a r 8 or T e x t . P a r s e r C o m b i n a t o r s . P a r s e c in ghci just to disambiguate some operation... Does that mean I'm not the only one longing for

:m +Data.ByteString.Lazy.Char8 as B

In that case I should probably submit a feature request for it.

+1 Importing modules in ghci is really annoying for several reasons: - Above mentioned. - Loose my imports on failed load (maybe we could keep the current bindings, imports until the whole load is finished?) - Super long prompt. Cheers, Johan

| > > Does that mean I'm not the only one longing for | > > | > > :m +Data.ByteString.Lazy.Char8 as B | > > | > > In that case I should probably submit a feature request for it. | > | > +1 | > | > Importing modules in ghci is really annoying for several reasons: | > | > - Above mentioned. | > - Loose my imports on failed load (maybe we could keep the current | > bindings, imports until the whole load is finished?) | > - Super long prompt. Add a feature request by all means! Simon