- Libraries - Haskell.org

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

Re: something akin to Java's "package" in libraries
by Marcin 'Qrczak' Kowalczyk 02 Mar '02

02 Mar '02

Thu, 28 Feb 2002 17:22:20 -0000, Simon Marlow <simonmar(a)microsoft.com> pisze: > However, I'd like to see if people really think that writing out the > full module names is really a problem in practice - in my (limited) > experience with the hierarchical libraries so far I don't mind > writing out the full module names in import lists at all, and I > even quite like to see the module names written out in full. I agree. > I must admit I don't like the idea of defaulting to importing > X if <package>.X doesn't exist, I'd prefer the two cases to be > syntactically distinct. Perhaps the convention should be that '.X' > means '<package>.X', and plain X is left alone. If at all, it could be '..X' because '..' is already used in export lists to mean "something should be filled in here, the compiler knows what" and there were rough ideas for '..' replacing parts of type signatures. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ QRCZAK

1 0

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

02 Mar '02

> I vaguely recall a brief discussion of this long ago, but > don't see any > reference to it on the libraries web page. What I had in mind is > something like: > > > > package Graphics.GL > > module Foo (...) > > where > > > > import X > > import Bar.Y > > import Z > > ... > > where the first conversion is > > module-name <- package-name ++ "." ++ module-name > > the larger issue would be how to convert imports to qualified > imports (and > module exports to qualified exports). i think (only my opinion) that > something like: > > import X > > should be qualified to > > import Graphics.GL.X as X > > unless Graphics.GL.X doesn't exist, in which case it gets defaulted to > > import X This is an interesting suggestion. However, I'd like to see if people really think that writing out the full module names is really a problem in practice - in my (limited) experience with the hierarchical libraries so far I don't mind writing out the full module names in import lists at all, and I even quite like to see the module names written out in full. On the other hand, I haven't been working with any modules that go more than 3 deep in the hierarchy, so I'd like to hear feedback from someone writing a library with multiple modules that lives deep in the hierarchy (Sven - perhaps you qualify with Graphics.Rendering.OpenGL.GL?). But I guess the packages concept helps when you want to graft a subtree of modules from one place in the hierarchy to another, right? I must admit I don't like the idea of defaulting to importing X if <package>.X doesn't exist, I'd prefer the two cases to be syntactically distinct. Perhaps the convention should be that '.X' means '<package>.X', and plain X is left alone. (oh, and there have been various other suggestions along these lines - have a look back through the mailing list archives). Cheers, Simon

3 2

POpen
by Jens Petersen 27 Feb '02

27 Feb '02

Hello, 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? Jens

2 1

library design conventions
by Hal Daume III 27 Feb '02

27 Feb '02

it says: > A function or action taking a some kind of state and returning a pair > consisting of a result and a new state, the result is the first element > of the pair and the new state is the second, see e.g. Random. unfortunatly, Random and the mapAccum{RL} functions don't agree at all. the accumulating map functions assume the state is in the first element and the new element is in the second, but random doesn't behave this way and it appears neither do the libraries. am i the only one bothered by this? i would prefer if at least the libraries would change and put the state in the first position of the pair. it's probably hopeless to get Random to change at this point, as with the mapAccum functions. - Hal -- Hal Daume III "Computer science is no more about computers | hdaume(a)isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

1 2