March 2002 - Libraries

RE: cvs-libraries ?
by Simon Marlow 21 Mar '02

21 Mar '02

> Should there be a cvs-libraries mailing list? There is, as of two days ago: http://www.haskell.org/mailman/listinfo/cvs-libraries Simon

1 0

cvs-libraries ?
by Ross Paterson 21 Mar '02

21 Mar '02

Should there be a cvs-libraries mailing list?

1 0

Axis of Evil
by Wanted! 20 Mar '02

20 Mar '02

1 0

RE: POpen
by Simon Marlow 19 Mar '02

19 Mar '02

> I guess you've just been busy with other things, but was the > patch I sent to add POpen to posix ok? It was fine - I've committed it modulo a couple of minor changes. Cheers, Simon

1 0

RE: POpen
by Simon Marlow 19 Mar '02

19 Mar '02

> > and there shouldn't be any problem with us just pulling it > > into the current Posix library for the time being. > > Sounds fine to me. Do you mean dropping it into > "libraries/base/GHC/Posix.hs"? I would drop the file into the tree as hslibs/posix/POpen.hs for now, and export popen and popenEnvDir from Posix. > Btw is most of hslibs expected to go into libraries? > How about all the posix stuff? The plan is to migrate everything useful from hslibs into libraries eventually. Deprecated functionality and old interfaces are being left behind, and someday we'll ship GHC without hslibs at all. Hugs is also going to move to using the contents of fptools/libraries for its base libraries soon. As regards the Posix library, I think we need a redesigned library that supports more of IEEE 1003.1-2001 (the latest incarnation of POSIX including all the extra bits from the Single Unix Spec). It certainly needs to be completely re-implemented: the current Posix library uses all kinds of old GHC features and libraries that we'd like to remove. > Yes, that's ok. Should I send you a new version with the > header updated, or? That would be great, thanks. Cheers, Simon

3 3

RE: something akin to Java's "package" in libraries
by Simon Marlow 05 Mar '02

05 Mar '02

> Another feature from Java that would be very nice in the module system > is package scope. Currently, if any two modules wish to share > bindings, > they have to be entirely public and thus importable by > anyone. But a big > library often (practically always) has some common > definitions that need > to be shared by many modules in the library, but still are internal to > the library and not meant for public consumption. A package > scope would > provide a means to enforce this. I wouldn't advocate having a separate mechanism to support this. If a module "owns" a node in the hierarchy, then it also owns all children of that node, so it can use nested modules for internal functionality. This doesn't actually *enforce* the separation of the namespace because anyone can directly import the internal module, but as long as clients stick to the published interfaces it works fine. Cheers, Simon

1 0

RE: FW: MonadFix
by Simon Marlow 05 Mar '02

05 Mar '02

> On Mon, Mar 04, 2002 at 09:40:48AM +0000, Levent Erkok wrote: > > I agree that nthFix is mainly useful in proofs. Similarly for > > paramFix. But if we are having a separate library for "fix"-like > > functions, I don't see any harm in putting them there as well. > > I was thinking that if there's only one really useful function (fix) > it hardly warrants a whole module. > > > I used the name "traceFix" to avoid clash with the "trace" debugging > > primitive. It sounds too much like a debugging function in any case. > > Ah, but we have modules for namespace control. On the other > hand, this > function is probably of no use to any module other than Arrow > (so might > as well be there). Control.Function sounds like a good idea. I've been looking for somewhere to put these too: id, (.), const, flip, until. Cheers, Simon

1 0

RE: FW: MonadFix
by Simon Marlow 04 Mar '02

04 Mar '02

> Why don't we put "fix" into another library, and let MonadRec > Arrow, etc. import it? Fixed-point operators show up quite often > to deserve a library of their own: If all I care about is > "fix", I shouldn't be forced to "import MonadRec". This new > library can include various flavors of fix: > > fix :: (a -> a) -> a -- usual fixed-points > fix f = let a = f a in a > > nthApprox :: Integer -> (a -> a) -> a -- > approximations to fix > nthApprox n f = (iterate f undefined) !! n > > trace :: ((a, u) -> (b, u)) -> (a, b) -- traces > trace f a = let (b, u) in f (a, u) in b > > pFix :: ((a, u) -> u) -> (a -> u) -- parameterized fix > pFix f a = let (a, u) = f u in u > > Then MonadRec, Arrow, or whoever just needs fixed-point operators > can import it from there.. This sounds fine to me. It should probably go in Control.Fix. Levent: would you like to suggest a full contents for this library? Cheers, Simon

3 4

RE: FW: MonadFix
by Simon Marlow 04 Mar '02

04 Mar '02

> On Monday 25 February 2002 10:42 am, Simon Marlow wrote: > > This sounds fine to me. It should probably go in > Control.Fix. Levent: > > would you like to suggest a full contents for this library? > > Sorry for the late reply. Modulo names, I think the attached library > should do it. Thanks Levent. I plan to import this as Control.Fix, and remove 'fix' from Control.Monad.Fix, unless anyone has any objections. Cheers, Simon

1 0

RE: POpen
by Simon Marlow 04 Mar '02

04 Mar '02

> I was wondering if there is any interest in having POpen > > http://www.01.246.ne.jp/~juhp/haskell/popenhs/ > > included in the new haskell libraries? Yes, in principle. Although popen() is part of Posix these days so if/when the Posix library is rewritten it should become part of that. http://www.opengroup.org/onlinepubs/007904975/functions/popen.html I just looked at the tarball (wow, 276k of packaging goop for 3k of code, that's pretty impressive :-) and there shouldn't be any problem with us just pulling it into the current Posix library for the time being. Would you mind changing the license to a BSD-style license? If not, we'll have to put the code in a separate package in another part of the repository (see the libraries document for the current licensing policy). Cheers, Simon

2 1