Iavor Diatchki writes:
... by the way i don't think this would be a problem if relative names were added to the module system, as a porgrammer could use an absolute name for the system library, and a relative name for the project monads. but we have already discussed that.
The topic of relative module names is still open...
it seems that most people don't want the library in Monad.* so i guess we should keep it in Control.Monad.*. then the next question is when to replace the current library with the modified one. i am not sure of the user base of the monad library, but i would rather do it sooner than later. i guess i should point out that the "new" library is not much different from the old one, and with exception of resumptions and the instances for the Monad* classes for continuations added after another transformer things should work fine (those two were not in the previous library anyways). if we keep the library under Unstable*, i doubt that anyone would use it, and this will slow down tracking of bugs etc.
So are you saying that it won't break much code, or it won't break any code? Either way, I'd be happy for it to be brought in without providing the old version - we make minor changes to library APIs all the time (only in new major releases of GHC, though).
there is also the problem of it being available only from CVS. i could make a package available from my web-page (or some other page), but then it would clash with the library in base. do you think it would be a good idea to split it from the base package? base seems huge as it is already.
Definitely! Ideally I'd like to see it distributed as a completely separate package (pending progress on the library distribution work that's going on). For now, moving it into a separate package under fptools/libraries/ would be fine. Cheers, Simon
On Thu, Jul 31, 2003 at 09:40:55AM +0100, Simon Marlow wrote:
Iavor Diatchki writes:
do you think it would be a good idea to split [monad transformers] from the base package? base seems huge as it is already.
Definitely! Ideally I'd like to see it distributed as a completely separate package (pending progress on the library distribution work that's going on). For now, moving it into a separate package under fptools/libraries/ would be fine.
Maybe it would make sense to move parsec out too.
Simon Marlow wrote:
it would clash with the library in base. do you think it would be a good idea to split it from the base package? base seems huge as it is already.
Definitely! Ideally I'd like to see it distributed as a completely separate package (pending progress on the library distribution work that's going on). For now, moving it into a separate package under fptools/libraries/ would be fine.
Maybe I'm a bit slow today, but what exactly is "it"? The modules below Control.Monad? Hmmm, they account for less than 3% of the object code of the base package, and requiring "-package monad" would immediately break lots of build scripts out there. I'm not sure if this is a good deal... Cheers, S.
Definitely! Ideally I'd like to see it distributed as a completely separate package (pending progress on the library distribution work that's going on). For now, moving it into a separate package under fptools/libraries/ would be fine.
Maybe I'm a bit slow today, but what exactly is "it"? The modules below Control.Monad? Hmmm, they account for less than 3% of the object code of the base package, and requiring "-package monad" would immediately break lots of build scripts out there. I'm not sure if this is a good deal... "it" is supposed to be a modification of the monad (transformer) library i.e. the files under Control.Monad.* (note that this does not include
hello, Sven Panne wrote: the module Control.Monad itself). i didn't think they are that widely used, would this really be a big problem? i am not too woried about the size on disk, althought things do add up. i think the big benefit of separating the monad library (and the others too) is that it can be updated (bugfixes, documentation, new versions etc) independently of the rest of the base package. bye iavor -- ================================================== | Iavor S. Diatchki, Ph.D. student | | Department of Computer Science and Engineering | | School of OGI at OHSU | | http://www.cse.ogi.edu/~diatchki | ==================================================
Ideally I'd like to see it distributed as a completely separate package
Iavor Diatchki
"it" is supposed to be a modification of the monad (transformer) library i.e. the files under Control.Monad.* (note that this does not include the module Control.Monad itself). i didn't think they are that widely used, would this really be a big problem? i am not too woried about the size on disk, althought things do add up. i think the big benefit of separating the monad library (and the others too) is that it can be updated (bugfixes, documentation, new versions etc) independently of the rest of the base package.
This sounds good to me. Being able to make library bugfixes happen on a faster scale than the compiler release schedule is a fine aim. If your API changes from the current Control.Monad.* are very small, as you suggest, then I'm happy for you to go ahead soon. As you say, most users only care about Control.Monad itself, with fewer people using the more esoteric transformer stuff, so breakage should not be a major problem. Regards, Malcolm
[sorry for not following this list closely, hope this interjection is appropriate..] given this recent excitement about Control.Monad and transformers, this might be a good opportunity to point to a previous thread here: http://haskell.org/pipermail/libraries/2002-November/000714.html Have these problems been addressed yet, i.e.: - separating standard instances of common classes for common types from other stuff, unlike in the Monad hierarchy (which surprisingly adds instances of Functor/Monad for Either and ((->)a) just because those happen to be one way to implement Errors and Environments), As Haskell doesn't have parameterized modules, my preference would be to single out such instances (and only those which are unambiguously standard) in separate modules, which should make their contents obvious, and which could be imported by any other module needing these instances (without getting other stuff as well) *and wishing to export them*. - not stealing, e.g., the Monad instance for Either in Control.Monad.Error, for a not-quite standard definition. My preference would be use of newtype to define, e.g., an abstract type in terms of Either, and to have the instances defined for that abstract type. Haskell's module system gives no control over instances, but does give control over types. That is, there would be one module providing, e.g., reader monads *without* ursurping instances of "global" classes for "global" types for that purpose, and *another* module providing "standard" instances for "global" classes/types. The latter would be good for quick hacks, the former for modular development - different purposes, different modules. Otherwise, there are conflicts when one combines two packages trying to define their own versions of these instances as part of whatever else they are trying to do (such as the Monad modules right now). There seemed to be some support for these suggestions last time, and as there seems to be a maintainer around now, this might be a good time to fix these things?-) Cheers, Claus
hello, C.Reinke wrote:
[sorry for not following this list closely, hope this interjection is appropriate..] not at all, there is an alwfull lot of stuff going to haskell, haskell-cafe, libraries, etc so i often miss things :-)
i think the issues bellow are addressed to some extent, but since i am not 100% sure i understtod the post, please ask again if my answer is not quite adequate. the philosophy i took with the modified monad transformer library is that it does not provide any instances for "standard classes" for "standard types". by this i mean that there are _no_ instances like: instance Monad (Either a) where ... instance Monad ((->) a) where ... etc. every transformer is defined using newytpe, and is actually exported as an abstract entity, so it is a completely new type that can only be manipulated thru' functions/methods defined in the library. the library defines a bunch of classes, and there are some instances for "standard types", for example: instance HasBaseMonad IO IO that should not be a problem, as there are no other sensible instances for this class. one (somewhat debatable) point is the way the monads (not the monad transformers) in the library are implemented: they are defined by applying the corresponding transformer to the identity monad, and this is done by simply using a type synonim. there was a short discussion if we should use newtype instead, but no final decision was reached. i kind of like the current way of doing things, but there was a concern about the type errors one gets. i did a few experiments and the type errors do not seem much worse, but if in the future that becomes a problem (or most people want newtypes) we could easily change that. is there demand to define instances for "standrd types", e.g. things like: instance Monad (Either a) where ... instance MonadError a (Either a) where ... i am not sure that this is a good idea as the monads in the library do the same job. bye iavor
given this recent excitement about Control.Monad and transformers, this might be a good opportunity to point to a previous thread here:
http://haskell.org/pipermail/libraries/2002-November/000714.html
Have these problems been addressed yet, i.e.:
- separating standard instances of common classes for common types from other stuff, unlike in the Monad hierarchy (which surprisingly adds instances of Functor/Monad for Either and ((->)a) just because those happen to be one way to implement Errors and Environments),
As Haskell doesn't have parameterized modules, my preference would be to single out such instances (and only those which are unambiguously standard) in separate modules, which should make their contents obvious, and which could be imported by any other module needing these instances (without getting other stuff as well) *and wishing to export them*.
- not stealing, e.g., the Monad instance for Either in Control.Monad.Error, for a not-quite standard definition.
My preference would be use of newtype to define, e.g., an abstract type in terms of Either, and to have the instances defined for that abstract type. Haskell's module system gives no control over instances, but does give control over types.
That is, there would be one module providing, e.g., reader monads *without* ursurping instances of "global" classes for "global" types for that purpose, and *another* module providing "standard" instances for "global" classes/types. The latter would be good for quick hacks, the former for modular development - different purposes, different modules.
Otherwise, there are conflicts when one combines two packages trying to define their own versions of these instances as part of whatever else they are trying to do (such as the Monad modules right now).
There seemed to be some support for these suggestions last time, and as there seems to be a maintainer around now, this might be a good time to fix these things?-)
Cheers, Claus
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
-- ================================================== | Iavor S. Diatchki, Ph.D. student | | Department of Computer Science and Engineering | | School of OGI at OHSU | | http://www.cse.ogi.edu/~diatchki | ==================================================
Hmmm, they account for less than 3% of the object code of the base package, and requiring "-package monad" would immediately break lots of build scripts out there. I'm not sure if this is a good deal...
I think a world with many small packages is better than one with a few large packages^* so I think we should move stuff out of the base package but, as we do so, we should look for ways to make the number of packages more manageable. Some ideas: 1) Package management systems could provide a package grouping feature where you can define groups like: good_stuff = haskell98 + base + posix + network This kind of thing is common in Debian packages. For example, installing the 'kde' package sucks in 50-100 other packages like mailers and editors. 2) Instead of specifying which packages you want when you invoke the compiler, the compiler could automatically give you all you have installed. This is probably what Hugs is going to do and will work as long as the hierarchial namespace is used to avoid name conflicts instead of using packages to avoid name conflicts. We will also have to make sure that our package mechanism has effective version-dependency features and that package descriptions use them. This is partly a technical issue and partly a social one. -- Alastair * My view that many small packages is better than a few big ones partly comes from my experience with Debian which does this very well. Although Redhat does have packages too, people tend to rely more on getting a fresh redhat CD (cf. installing the latest GHC with all the libraries it includes) so package granularity, accuracy of version dependencies isn't so important and, I think, doesn't receive as much attention as if it was relied on and tested by many people per day. People with experience of more monolithic systems (and who want Haskell packages to be that way too), should speak up.
So are you saying that it won't break much code, or it won't break any code? Either way, I'd be happy for it to be brought in without providing the old version - we make minor changes to library APIs all the time (only in new major releases of GHC, though). unfortunately it is not 100% compatable with the old library and some code will probably be broken. the more important changes are described in the README file in CVS, and also most of the library is documented (one could always write more of cousre :-) in short the main changes are probably the behaviour of "listen" in general, and the definitions of "fail","mzero", and "mplus" for some of
hello, Simon Marlow wrote: the transformers (Error in particular). also since there are some new functions, they could clash with already existing names in a module. and the module structure is changed to "column" format rather than the "diagonal" used in the old library. so i think code may break or not depending on what exactly was used, but it should not be hard to fix. of course people don't usually want to go and fix old code. bye iavor -- ================================================== | Iavor S. Diatchki, Ph.D. student | | Department of Computer Science and Engineering | | School of OGI at OHSU | | http://www.cse.ogi.edu/~diatchki | ==================================================
G'day all. On Thu, Jul 31, 2003 at 09:40:55AM +0100, Simon Marlow wrote:
Definitely! Ideally I'd like to see it distributed as a completely separate package (pending progress on the library distribution work that's going on). For now, moving it into a separate package under fptools/libraries/ would be fine.
This definitely is the right thing for now, but I think that it's not too early to start thinking about is what libraries we eventually want to be in the next Haskell standard library, and put that and only that into the base package. A good monad (transformer) library is one such thing, though admittedly it probably won't be exactly like the ones that we have now. Cheers, Andrew Bromage
participants (8)
-
Alastair Reid -
Andrew J Bromage -
C.Reinke -
Iavor Diatchki -
Malcolm Wallace -
Ross Paterson -
Simon Marlow -
Sven Panne