- Libraries - Haskell.org

RE: Library hierarchy, contd.
by Simon Marlow 25 May '01

25 May '01

> Dylan mentions "matrix classes" and then concludes: > > > Maybe "Computational" would be a better name than "Numeric"? > > I've been trying to demonstrate that there more to > "matrix" than just data structure or just simple linear > equation solver. It is easy to come up with the latter, > or with a set of primitive product operations. But people > seem to be ignoring the fact that there is much more to linear > algebra than those trivialities. Eigenproblems for > example... Dense cases, sparse cases and all that Pandorra > box of non-trivial engineering tools. > > These things are still alive, thank you very much, and > the papers are still written about them every day. Neither > the problems nor the papers are trivial. > > Yet they are being ignored in your hierarchy. > Please, mark at least some spot for them. And do not tie them > to "matrix" because "matrix" is just one specific representation > of operator algebra -- as I am showing in some modules > of mine, for example. > I do not care what name you choose. Computational? > Linear algebra? But please do not ignore them altogether. We're not ignoring these issues, sorry if you got that impression. I'd certainly like to see a suggestion (better still, a proposal) for organising these libraries from people such as yourself and Dylan. Cheers, Simon

1 0

RE: Library hierarchy, contd.
by Simon Marlow 24 May '01

24 May '01

> Me: > Likewise. I'm very happy with the broad structure now. There are > only minor nits left (such as already mentioned by other people, > e.g. FileFormat.Graphics -> FileFormat.Image). Already made that change in my local copy. Great - it looks like we're converging. One other nit which I forgot about: can we capitalise Xml and Html to XML & HTML to be consistent (I think we already agreed to do this). Cheers, Simon

3 2

Re: Library hierarchy, contd.
by Ashley Yakeley 24 May '01

24 May '01

At 2001-05-24 09:06, Malcolm Wallace wrote: >I vaguely remember agreeing the opposite - to use InitCaps throughout >rather than ALLCAPS. Whatever. Strictly, 'HTML' and 'XML' are IC... -- Ashley Yakeley, Seattle WA

1 0

Re: Library hierarchy, contd.
by Mike Gunter 23 May '01

23 May '01

> FileFormat -- 'Codec' might be a more accurate name? > Graphics > Jpeg > Ppm > Png A nit: "Image" not "Graphics" would be consistent with the terminlogy of those fields. mike

1 0

lookupFM vs Prelude.lookup
by Alastair Reid 08 May '01

08 May '01

This is somewhat well known but I just got caught by it yet again so I'd like to add it to the list of things that need fixed in hslibs. Prelude.lookup and lookupFM _almost_ have the same type: Prelude.lookup :: <context> => a -> [(a,b)] -> Maybe b lookupFM :: <context> => FM a b -> a -> Maybe b Close enough that your mind treats them the same, different enough that Haskell won't. It'd be much better if these took their arguments in the same order. That is, either: Prelude.lookup :: <context> => [(a,b)] -> a -> Maybe b lookupFM :: <context> => FM a b -> a -> Maybe b or: Prelude.lookup :: <context> => a -> [(a,b)] -> Maybe b lookupFM :: <context> => a -> FM a b -> Maybe b Despite being on the library committee at the time, I don't understand why H98 went for the argument order it did (I prefer the FiniteMap order) but, since it's the standard, I propose that they get swapped in FiniteMap when things get reorganised. (I know this will be very painful for people who use FMs heavily (e.g., GHC) but it's easier to make these changes relatively early.) -- Alastair Reid reid(a)cs.utah.edu http://www.cs.utah.edu/~reid/ ps Since FM provides, essentially, the same functionality as Arrays, it really ought to have a much more similar interface. I'll leave off the details for now (just apply s/FiniteMap/Array/ to the types of FM functions and check them off against the Array interface). pps Is there a list of things to be done to hslibs? It'd be good to have a place in a CVS tree somewhere where we could add things or to have John Hughes' Standard Haskell web page software (http://www.cs.chalmers.se/~rjmh/Haskell/Messages/Display.cgi?id=0) or something. The current mail archive isn't as good because it doesn't have enough structure and there's no place you can go to to find what is currently agreed on, what is still open to discussion and what is being ignored. (The same goes for the ffi list.)

1 0

Re: Dimensional analysis with fundeps (some physics comments)
by Ashley Yakeley 10 Apr '01

10 Apr '01

I'm cross-posting this to the Libraries list... At 2001-04-10 18:02, Fergus Henderson wrote: >Still, the need to insert explicit `toUnits' is >annoying, and it would be nice to have a system where every number was >already a dimensionless unit. That's easy: -- type Unit rep = Dimensioned Zero Zero Zero rep; instance (Real a) => Real (Unit a) where { -- put instances here }; -- Of course you'll have to appropriately declare superclasses of Real, such as Num, Ord, Show, Eq etc. -- Ashley Yakeley, Seattle WA

3 2

Dimensions
by Ashley Yakeley 10 Apr '01

10 Apr '01

This builds on anatoli's work. -- Ashley Yakeley, Seattle WA

1 0

Re: Dimensional analysis with fundeps (some physics comments)
by Ashley Yakeley 10 Apr '01

10 Apr '01

At 2001-05-01 18:28, Terrence Brannon wrote: >"has Ashley >shown in her example a means of automating a toUnits imperative in >Haskell that must be done explicitly in Mercury?" ...his... -- Ashley Yakeley, Seattle WA

1 0

RE: FW: lazy file reading in H98
by Simon Peyton-Jones 09 Apr '01

09 Apr '01

I'm working on this text right now. Check out http://research.microsoft.com/~simonpj/tmp/haskell98-library-html/ and see if you think it's improved Simon | -----Original Message----- | From: Malcolm Wallace [mailto:Malcolm.Wallace@cs.york.ac.uk] | Sent: 03 April 2001 17:04 | To: libraries(a)haskell.org | Subject: Re: FW: lazy file reading in H98 | | | > (1) At least, the definition should say that the behaviour | > is undefined if a program ever writes to a file that it | > has read with `readFile' or `hGetContents' before. | | The Library Report is already stronger than this. The | behaviour is fully defined: an error should be raised. | Here's what it says: | | > Implementations should enforce as far as possible, locally | to the Haskell | > process, multiple-reader single-writer locking on files. | ... If any | > open or semi-closed handle is managing a file for input, | new handles | > can only be allocated if they do not manage output. | > ... | > Error reporting: the openFile computation may fail with | > isAlreadyInUseError if the file is already open and cannot be | > reopened. | | The only very slightly confusing aspect is that the handles | used by "readFile" and "writeFile" are internal, not written | directly by the programmer. Perhaps the description of this | behaviour should be moved up from the 11.3.1 "Opening Files" | subsection to the enclosing 11.3 section, because it is more | generally applicable. | | Subsection 11.2.1 "Semi-closed Handles" should mention | "readFile" in addition to "hGetContents". It could also | explicitly refer to the multiple-reader single-writer | restriction, which is not otherwise mentioned here. | | Regards, | Malcolm | | _______________________________________________ | Libraries mailing list | Libraries(a)haskell.org | http://www.haskell.org/mailman/listinfo/libraries |

3 4

RE: FW: lazy file reading in H98
by Simon Peyton-Jones 09 Apr '01

09 Apr '01

| Simon doesn't want to make changes to Haskell. My opinion is | that the current definition of readFile and hGetContents is | fine. They are useful when used with a bit of care. Some | remarks should make the reader of the report aware of the | caveats. (I'm not saying that I couldn't imagine some useful | additional functions for lazy reading and writing.) That's exactly what I think. The current IO libraries are far from perfect, but what I want to do in the H98 Report is simply to document clearly what they do and don't do. Improving them is a job for the Libraries group, and I hope we'll take up the challenge. Simon

1 0