February 2002 - Libraries

Re: Graphics hierarchy
by Ashley Yakeley 27 Feb '02

27 Feb '02

At 2002-02-27 00:44, Sven Panne wrote: > * It's unclear what Graphics.Format is supposed to do exactly. > Could somebody explain this? Perhaps functions of the form encodePNG :: Image -> [Word8] decodePNG :: [Word8] -> Maybe Image ...? -- Ashley Yakeley, Seattle WA

2 1

RE: Graphics hierarchy
by Simon Marlow 27 Feb '02

27 Feb '02

> The currently proposal for the Graphics hierarchy looks like > this (IIRC): > > Graphics > UI > Drawing > Format > > I propose changing "Drawing" to "Rendering", because this a > more common > term in computer graphics. But I'm no native speaker, so I'd > like to hear > some comments on this. I like "Rendering". > Another problem is that in "real world" APIs the above > subcategeories are > often mixed up a bit. Have a look at the following APIs resp. Haskell > libraries: > > Clean ObjectIO > Direct3D > FRAN > FranTk > Fudgets > Functional Metapost > GIFWriter > GLUT > GTK+ > Haven > HGL > Inventor > MOTIF > OpenGL > Pan > TclHaskell > Win32 > X toolkit intrinsics > Xaw > Xlib > Xmu Ok, I think I might be tempted to put the X libraries in their own hierarchy, because they don't fit completely into either Rendering or UI: Graphics Rendering HGL OpenGL Direct3D Pan FRAN Haven UI ObjectIO FranTk Fudgets Motif Gtk+ GLUT TkHaskell Format GIF PNG JPEG TIFF ... X Xt Xlib Xmu Xaw > Functional Metapost > Inventor I don't know enough about these. > Win32 The Win32 API includes not just Graphics but also Systemy stuff, so there are two options: either it has its own top-level category, or we scatter the various parts of the Win32 API around the hierarchy (a similar problem arises with Posix). I think I prefer the former. Cheers, Simon

4 4

Graphics hierarchy
by Sven Panne 26 Feb '02

26 Feb '02

[ As suggested by The Grand Marshal of Libraries (tm), I'm moving a thread from the HOpenGL list to this one, widening its scope a bit. ] The currently proposal for the Graphics hierarchy looks like this (IIRC): Graphics UI Drawing Format I propose changing "Drawing" to "Rendering", because this a more common term in computer graphics. But I'm no native speaker, so I'd like to hear some comments on this. Another problem is that in "real world" APIs the above subcategeories are often mixed up a bit. Have a look at the following APIs resp. Haskell libraries: Clean ObjectIO Direct3D FRAN FranTk Fudgets Functional Metapost GIFWriter GLUT GTK+ Haven HGL Inventor MOTIF OpenGL Pan TclHaskell Win32 X toolkit intrinsics Xaw Xlib Xmu Where should we put them in the new hierarchy? Do we need more/other subcategories? Cheers, S. -- Sven Panne Fon: +49/89/99567000 Fax: +49/89/99567461 BetaResearch GmbH, Betastr. 1, D-85774 Unterfoehring mailto:Sven_Panne@BetaResearch.de http://www.betaresearch.de

2 1

RE: Graphics hierarchy
by Simon Marlow 26 Feb '02

26 Feb '02

> > The Win32 API includes not just Graphics but also Systemy stuff, so > > there are two options: either it has its own top-level category, > > [...] > > I'd prefer that, too. > > Has anything been decided about POSIX yet? Nope. But I'm thinking that Posix should be divided into two, with the networking stuff going in Network.Posix (an evolution of the current SocketPrim library) and the rest in System.Posix, possibly further subdivided within there. Unfortunately this breaks our rule of naming libraries by functionality, but again I think I prefer System Posix to System Directory Posix IO Posix Time Posix etc. Cheers, Simon

1 0

FW: Straightforward conversion from Int <-> Word
by Simon Peyton-Jones 26 Feb '02

26 Feb '02

Dear library folk Is this as Haskell library issue? Shouldn't this be a blessed function? Simon -----Original Message----- From: Julian Seward (Intl Vendor) [mailto:v-julsew@microsoft.com] Sent: 25 February 2002 16:57 To: jmaessen(a)alum.mit.edu; glasgow-haskell-users(a)haskell.org Subject: RE: Straightforward conversion from Int <-> Word I've found this annoying in the past, and have resorted to hitting it on the head (GHC-specifically) with a blunt instrument: intToNat :: Int -> Word intToNat (I# i#) = W# (unsafeCast# i#) This probably defeats the good intentions of the FFI designers, but it kinda seems like it'll work on all reasonable architectures. J | -----Original Message----- | From: Jan-Willem Maessen [mailto:jmaessen@alum.mit.edu] | Sent: Monday, February 25, 2002 4:46 PM | To: glasgow-haskell-users(a)haskell.org | Subject: Straightforward conversion from Int <-> Word | | | I've cast about a bit and haven't been able to find the appropriate | functionality, so I'm asking here. | | I'd like to convert Int32 to and from Word32 in the good old-fashioned | bitwise fashion (perserving modular arithmetic). I have the following | code to show what I mean: | | intToNat i | | i >= 0 = fromIntegral i | | otherwise = fromIntegral (i - minBound) + negBound | where negBound = fromInteger . negate . toInteger $ | (minBound :: Int) | | One might think that "intToWord32" and "word32ToInt" in lang/Word | would do what I want---but no! These are depracated, and I must use | fromIntegral, which will only perform the conversion correctly for the | portions of the numeric range which overlap. | | How do I do the straightforward conversion module 2^32? I'm sure it's | buried in there somewhere... I can't even turn up an appropriate type | signature, though. | | -Jan-Willem Maessen | | _______________________________________________ | Glasgow-haskell-users mailing list Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users | _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users(a)haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

Library Source-Based Documentation
by Ashley Yakeley 25 Feb '02

25 Feb '02

At 2002-02-25 04:50, Simon Marlow wrote (on Cafe): >For the next release of GHC, I'm hoping we can do a much better job, >though not just by writing more documentation but by generating more of it >automatically from the source code. That's the plan; we don't have >anything concrete yet. Do you plan to use HDoc or HaskellDoc or somesuch? I ask because I'm interested in doing the same thing for my code, and it would be nice to use the 'standard' source doc system as set by the standard libraries. -- Ashley Yakeley, Seattle WA

1 0

LazyArray, Supply libraries...
by Jan-Willem Maessen 25 Feb '02

25 Feb '02

Hello all - As it seems there's continued interest in the LazyArray library outside of the small circle of HBCLibs users, it seems like there ought to be a place for it in the Haskell library hierarchy. I have working code that we've been using for several months now, but which I cleaned up and documented a bit over the weekend. I posted the link to Haskell-Cafe on Saturday, but here it is again: http://www.csg.lcs.mit.edu/~earwig/haskell-lib/ The LazyArray library is ready to ship, and I'm eager to donate it to the cause if it's wanted. It could, for example, be added to hslibs or given a place in the Grand New Library Hierarchy. What hoops must be jumped through? The Supply library is not as well tested; the old library proposal mentioned a "LibSupply" of generic splittable supplies, though, and I can find no actual implementation or even a proposed interface beyond the existence of the type "Supply a". I suspect it will work fine in its present form, but would like to deal with the following: * If you know of another implementation, could you please send me a pointer? I'll try to get a united interface. I suspect existing LibSupply -ish implementations don't implement fmap and zip-like functions, but I'd love to be pleasantly surprised. I'm not totally satisfied with my function names, and would love to compare notes with another implementation if one exists. * Along the same lines, I'd love to hear comments on the functionality. Too much? Awful names? * I want to re-code NameSupply from HBCLibs using Supply. (I already ported NameSupply to GHC, which is what gave me enough clue to write Supply in the first place.) * It'd be nice to do an implementation of Random in terms of Supply as well. I suspect this would actually improve the kludgey Random in hugs at least. I don't really use Random regularly myself, but re-coding the hugs library should be easy enough that it won't be any worse than it already is. * I'd like to switch the Eager Haskell compiler over to a re-coded NameSupply to reinforce my confidence in the implementation. Note the other stuff mentioned on the web page will need a lot more work to be shippable. I urgently needed enumerable, joinable maps, but I haven't actually found the time to deploy them yet. Most of the other libraries depend on precursors of joinable fast sets/maps. Jan-Willem Maessen

1 0

RE: Graphs
by Simon Peyton-Jones 25 Feb '02

25 Feb '02

Jan-Willem Maybe you might consider proposing some of these useful libraries to populate the new libraries structure for Haskell? http://www.haskell.org/~simonmar/libraries/libraries.html Simon | -----Original Message----- | From: Jan-Willem Maessen [mailto:jmaessen@alum.mit.edu] | Sent: 23 February 2002 17:54 | To: haskell-cafe(a)haskell.org | Cc: David Feuer | Subject: Re: Graphs | | | David Feuer <dfeuer(a)cs.brown.edu> writes: | > I seem to remember an article about functional graph | algorithms using | > extra-lazy arrays. Anyone know if these arrays have | appeared in any | > mainstream implementation? | | I assume you're referring to this paper by Thomas Johnsson: | | @Article{lazyArray, | author = {Johnsson, Thomas}, | title = {Efficient Graph Algorithms Using Lazy | Monolithic Arrays}, | journal = JFP, | year = 1998, | volume = 8, | number = 4, | pages = {323--333}, | month = {July} | } | | He uses similar techniques to do whole-program flow analysis | of Haskell programs, a clever bit of coding described in the following | paper: | | @inproceedings{grinHeap, | AUTHOR = "Johnsson, Thomas", | TITLE = "Analysing Heap Contents in a Graph Reduction | Intermediate Language.", | booktitle = Proc # "Glasgow Functional Programming Workshop", | address = "Ullapool 1990", | MONTH = "August", | YEAR = 1991 | } | | The LazyArray library is part of the standard hbc | distribution. The Eager Haskell compiler depends on it (you | can get very nice static hash tables this way, among other | things). As a result, I've done a port of the library to GHC | (and, I think, hugs). I should note that most of the hints | required to pull off the implementation were found in the | "State in Haskell" paper by Simon PJ and John Launchbury. | The library is available (along with a few other useful | snippets, like universal splittable supplies) here: | http://www.csg.lcs.mit.edu/~earwig/haskell-lib/ -Jan-Willem Maessen _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

1 0

Complex Rational
by Ashley Yakeley 21 Feb '02

21 Feb '02

I notice I can't use the type "Complex Rational" because Complex wants a RealFloat (which Rational isn't). It looks like it's the 'abs' in Num that's the problem, it wants to return the magnitude, and for that it needs sqrt. Kind of annoying if you're only using the other members of Num... -- Ashley Yakeley, Seattle WA

1 0

Re: POSIX:2001 now available online
by Marcin 'Qrczak' Kowalczyk 10 Feb '02

10 Feb '02

Date: Thu, 07 Feb 2002 16:05:22 +0000 From: Markus Kuhn <Markus.Kuhn(a)cl.cam.ac.uk> Subject: POSIX:2001 now available online To: linux-utf8(a)nl.linux.org (linux-utf8) The revised POSIX standard, which has been merged with the Single UNIX Specification is now available online in HTML! For your bookmarks: http://www.opengroup.org/onlinepubs/007904975/toc.htm Also: http://www.UNIX-systems.org/version3/ http://www.opengroup.org/comm/press/30jan02.htm Markus -- Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK Email: mkuhn at acm.org, WWW: <http://www.cl.cam.ac.uk/~mgk25/> -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/

1 0