February 2002 - Libraries

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

something akin to Java's "package" in libraries
by Hal Daume III 27 Feb '02

27 Feb '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 , similarly for Bar.Y, gets qualified to: import Graphics.GL.Bar.Y as Y unless that doesn't exist, in which case it stays as it is. i suppose this presents a problem if there's a module Y in your package and a module Y which isn't and you want to only import the other one. i'm not entirely sure how java handles this, but from my fairly extensive experience in java, it's done well and i never had any problems with it in 50k+ loc. has this been discussed/considered at all? - 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 0

Re: Graphics hierarchy
by Ashley Yakeley 27 Feb '02

27 Feb '02

At 2002-02-27 01:07, Ketil Z. Malde wrote: >-- probably elsewhere in the hierarchy >class FileFormat a where > encode :: a -> [Word8] > decode :: [Word8] -> a > > >instance FileFormat PNG where > encode = ... > decode = .. I prefer ML-style structures/functors in this particular instance: data FileFormat a = MkFileFormat { encodeFile :: a -> [Word8], decodeFile :: [Word8] -> Maybe a }; formatPNG :: (Image img) => FileFormat img; formatJPEG :: (Image img) => JPEGCompressionFactor -> FileFormat img; formatUTF8 :: FileFormat String; >class Image a where > rotate :: a -> Int -> a > scale :: a -> Int -> Int -> a > >Maybe compose/blend images? Altering alpha and gamma, color >manipulation? Sounds like a serious project, with the possibility of plenty of complication. -- Ashley Yakeley, Seattle WA

4 4

Control.Monad.Monoid
by Ross Paterson 27 Feb '02

27 Feb '02

Though Monoid is used by several modules in Control.Monad, it doesn't have anything to do with monads itself, so it probably doesn't belong there. Data?

1 0

RE: Graphics hierarchy
by Simon Marlow 27 Feb '02

27 Feb '02

> Simon Marlow wrote: > > Thanks, I'll update my copy of the hierarchy and keep it here: > > http://www.haskell.org/~simonmar/lib-hierarchy.html > > Perhaps a pointer to this and the library document would be useful in > the "about" paragraph at > http://haskell.org/mailman/listinfo/libraries. Good idea; done. Cheers, Simon

1 0

RE: Graphics hierarchy
by Simon Marlow 27 Feb '02

27 Feb '02

> To summarize the recent discussion, here a proposal for a part of the > library organization: Thanks, I'll update my copy of the hierarchy and keep it here: http://www.haskell.org/~simonmar/lib-hierarchy.html at some point I should put this in the main libraries document, and make it clear which modules are part of the "core" libraries. > Format > GIF > JPEG > PNG > TIFF I think we had already agreed to move this sub-hierarchy under FileFormats (see the hierarchy at the link above). > HGL > X11 > Xaw > Xlib > Xmu > Xt > System > POSIX > Files > IO > Process > Win32 Win32 includes both System and Graphics stuff, so shouldn't it go at the top level? > * Whether the POSIX/Win32 hierarchies should be split up on a > functional basis or not has already been debated, but I can't see > any real consensus here. How should we proceed? Someone needs to come up with a proposal and some code, and we go from there :-) Cheers, Simon

2 1