October 2002 - Haskell

Enum on Float/Double
by George Russell 23 Oct '03

23 Oct '03

The situation with Enum on Ratio is pretty bad but at least it's not hopeless, since rational numbers are at least exact. But for Float/Double it seems to be a total disaster area. Since it seems to be impossible to abolish Enum Float/Double altogether, would it at least be possible to make it rather more useful, by making succ x return the next representable float after x (or x if x is non-finite) and pred x the previous representable float. This would (a) be useful; (b) make mathematical sense; (c) is tricky to implement with the existing primitives. Before someone else points it out, this is of course unimplementable should someone in the future implement infinite-precision reals in Haskell, but as (barring a solution to the halting problem) Eq would be as well, that does not bother me. My preference would be for succ (+-0) to return the smallest positive real, since then you could define succ x to be the unique y with x < y and forall z . z < y => not (x < z), where such a y exists, and I'm not sure if the Haskell standard knows about signed zeros. Feri wrote > Everybody working with floats should know their quirks While in an ideal world, everyone who represented a mouse position or anything else as a float should have a PhD in numerical analysis, in practice they do not. Indeed I think the Haskell Library Report contains quite a few examples of floating point code which a numerical analyst would have written rather better. So I don't think it's good enough to treat every Float/Double operation as if it had an implicit "UNSAFE" flag indicating that the compiler was entitled to wierd behaviour only comprehensible to experts, as seems to be the case with floating enumerations now.

8 11

tuple component functions
by trb＠eastpac.com.au 03 Jan '03

03 Jan '03

S.D.Mechveliani writes: > As Haskell has the standard functions fst, snd to decompose (a,b), > maybe, it worths to provide also > tuple31, tuple31, tuple31, > ... > tuple51, tuple52, tuple53, tuple54, tuple55 > > for the tuples of n = 3,4,5 ? I've found some of these useful, except I named them differently: > fst3 :: (a,b,c) -> a > fst3 (x,_,_) = x > snd3 :: (a,b,c) -> b > snd3 (_,x,_) = x > thd3 :: (a,b,c) -> c > thd3 (_,_,x) = x .... never got around to quadruples etc. I also defined (some of these may be untested): > tripl :: a -> (a,a,a) > tripl x = (x,x,x) > curry3 :: ((a, b, c) -> d) -> a -> b -> c -> d > curry3 f x y z = f (x, y, z) > uncurry3 :: (a -> b -> c -> d) -> ((a, b, c) -> d) > uncurry3 f t = f (fst3 t) (snd3 t) (thd3 t) > applyTriple :: (a -> b, a -> c, a -> d) -> a -> (b,c,d) > applyTriple (f,g,h) x = (f x, g x, h x) > cross3 :: (a -> b, c -> d, e -> f) -> (a,c,e) -> (b,d,f) > cross3 (f,g,h) (x,y,z) = (f x, g y, h z) > mapTriple :: (a -> b) -> (a, a, a) -> (b, b, b) > mapTriple = cross3 . tripl > applyFst3 :: (a -> b) -> (a, c, d) -> (b, c, d) > applyFst3 f = applyTriple (f . fst3, snd3, thd3) > applySnd3 :: (a -> b) -> (c, a, d) -> (c, b, d) > applySnd3 f = applyTriple (fst3, f . snd3, thd3) > applyThd3 :: (a -> b) -> (c, d, a) -> (c, d, b) > applyThd3 f = applyTriple (fst3, snd3, f . thd3) > applyArgs3 :: (a -> b) -> (c -> d) -> (e -> f) -> (b -> d -> f -> g) -> (a -> c -> e -> g) > applyArgs3 af1 af2 af3 f = \x y z -> f (af1 x) (af2 y) (af3 z) > rotl :: (a -> b -> c -> d) -> (b -> c -> a -> d) > rotl f y z x = f x y z > rotr :: (a -> b -> c -> d) -> (c -> a -> b -> d) > rotr f z x y = f x y z > rotl4 :: (a -> b -> c -> d -> e) -> (b -> c -> d -> a -> e) > rotl4 f y z t x = f x y z t > rotr4 :: (a -> b -> c -> d -> e) -> (d -> a -> b -> c -> e) > rotr4 f t x y z = f x y z t Some more combinators (only for pairs so far): > twin :: a -> (a,a) > twin x = (x,x) > swap :: (a,b) -> (b,a) > swap (x,y) = (y,x) -- apply a pair of functions to one argument > applyPair :: (a -> b, a -> c) -> a -> (b, c) > applyPair (f, g) x = (f x, g x) -- apply a pair of functions to a pair > cross :: (a -> b, c -> d) -> (a, c) -> (b, d) > cross (f, g) = applyPair (f . fst, g . snd) -- compose a pair of functions onto one function > dotPair :: (a -> b, a -> c) -> (d -> a) -> (d -> b, d -> c) > dotPair (f, g) h = (f . h, g . h) -- compose a pair of functions onto a pair of functions > dotCross :: (a -> b, c -> d) -> (e -> a, f -> c) -> (e -> b, f -> d) > dotCross (f, g) (h, i) = (f . h, g . i) > mapPair :: (a -> b) -> (a, a) -> (b, b) > mapPair = cross . twin > applyFst :: (a -> b) -> (a, c) -> (b, c) > applyFst f = applyPair (f . fst, snd) > applySnd :: (a -> b) -> (c, a) -> (c, b) > applySnd f = applyPair (fst, f . snd) > applyArgs :: (a -> b) -> (c -> d) -> (b -> d -> e) -> (a -> c -> e) > applyArgs af1 af2 f = \x y -> f (af1 x) (af2 y) > betweenFst :: (a -> b -> c) -> (a, d) -> (b, e) -> c > betweenFst = applyArgs fst fst > betweenSnd :: (a -> b -> c) -> (d, a) -> (e, b) -> c > betweenSnd = applyArgs snd snd I find these combinators useful, and probably other people have their own versions - it would be nice to get them standardised, so we all speak the same language. By standardised, I mean a prominent version that will be adopted by users, not necessarily a committee process. Tim

3 2

ICFP programming contest
by trb＠eastpac.com.au 03 Jan '03

03 Jan '03

Michael Hobbs writes: > Just took a look at the results for the ICFP contest. Am I correct in > assuming that "LA" stands for Lennart Augustsson and that "Si^3" stands > for Simon Marlow, Simon Peyton-Jones, Sigbjorn Finne? Is there a URL for the results ? Tim

2 1

HC&A Report (November edition) - LAST CALL
by C.Reinke 31 Oct '02

31 Oct '02

Dear Haskellers, over the last weeks, more and more of you have (been;-) volunteered to provide short summaries of recent and planned activities in your area of work with or on Haskell (for details, and for the current status, see http://www.haskell.org/communities/ , and the list of topics there: http://www.haskell.org/communities/topics.html ). Those summaries, as far as they haven't reached me already (special thanks to those early contributors!-), are due in this week (of which there isn't much left..), and after putting everything together, the third edition of the collective report should get out to this list early next month. The web page shows which areas are covered, and which summaries have reached me. --------------------------------------------------------------- ** This is the FINAL CALL for CONTRIBUTIONS to this edition. ** --------------------------------------------------------------- So, please, have a last look at the web page, and check for: missing topics? If your favourite Haskell topic isn't covered yet, get in touch with me as soon as possible (preferably by sending in a summary, but at least by naming possible contacts). This also applies if your topic is listed, but no contact has come forward yet! If you've released your latest and greatest Haskell software during the last six months, and want it to be represented, NOW is the last opportunity to send in a paragraph or two. This might also apply if you're in the final stages of releasing your software, and are certain to get it out over the next weeks. missing research groups? We've presently only got contacts for 4 of the groups.. project-pings? See recent discussion here about "Active Haskell development and libraries" - if you're maintaining some Haskell software, even if there haven't been any non-maintenance changes, please let me know! Otherwise, Haskellers might assume that your software is gathering dust and is no longer actively supported. micro-reports? late-breaking news?-) If you don't have any big project/group/area to report on, you might still want to let the Haskell community know that you're there and what you are working on. Just drop me a line or two on your work, and a link to your home page. new tips, tricks, tutorials, textbooks, journal issues? Published a Haskell textbook recently?-) Or perhaps you're working on a new web-based tutorial on how to get more out of Haskell software X? Any new guided tours of Haskell, or of aspects of developing Haskell software? If you have, or know about such a valuable resource, please send me a link and a brief description. Ultimately, all these things should be linked from the Haskell bookshelf: http://haskell.cs.yale.edu/bookshelf/ or, if it's a research publication, from Jim Bender's Online Bibliography of Haskell Research: http://haskell.readscheme.org/ Haskell jobs and services? Are you offering Haskell consultancy or training? Or are you looking for such? Are you working in an area where there aren't enough Haskellers with the domain-knowledge you need? A small entry in the HC&A report is a good way to let people know! missing reports? If you've promised a report, remember to send it to me, now!-) missing emails? If I've asked for your help, could you please let me know whether or not you'll be able to provide a report?-( Cheers, Claus -- Haskell Communities and Activities Report (November 2002 edition) All contributions are due in by the end of October! http://www.haskell.org/communities/

1 0

RE: precedence bug with derived instances
by Simon Peyton-Jones 30 Oct '02

30 Oct '02

Some last-ditch H98 stuff. I have the proofs now and have to send them back this week. Changes will become impossible (or at least much harder) after that. Ah well, I'm sure more errors will come to light. Simon | > | (3) Section D.4 gives the expected rule: | > | | > | head (readsPrec d (showsPrec d x "")) == (x,"") | > | | > | Why should this not be: | > | | > | readsPrec d (showsPrec d x "") == [(x,"")] | > | > I can't think why not, unless there is a shorter valid parse, which I | > suppose is conceivable. I'd rather not change this. | | In fact, neither rule above is true for the example given in section D.5. | To see this, run the following program: | | infix 5 :^: | data Tree a = Leaf a | Tree a :^: Tree a deriving (Eq, Ord, Read, Show) | main = mapM_ trial [0..10] | where trial d = print (readsPrec d (showsPrec d x "") :: [(Tree Int, | String)]) | x = Leaf 1 :^: Leaf 2 Uh huh. For readsPrec 0 "Leaf 1 :^: Leaf 2" we get [(Leaf 1, " :^ Leaf 2"), (Leaf1 :^: Leaf 2, "")] That is, there are two parses, and the shortest parse comes first. Same is true for Hugs. Not unreasonable, actually, and nothing in the specification seems to preclude this. I can only make minimal changes now. I suspect the smallest change is to require that (x,"") `elem` readsPrec d (showsPrec d x "") This weakens the existing equation by not requiring (x,"") to be the first parse returned. Dean writes: | Perhaps we want: | | readsPrec should be able to parse the string produced by showsPrec, and | should deliver the value that showsPrec started with. That is, the list | result of | | readsPrec d (showsPrec d x "") | | should contain exactly one pair whose second element is "", and the first | element of that pair should be equivalent to x. I don't understand this. What does "equivalent" mean? And how does this differ from the (incorrect) claim that readsPrec d (showsPrec d x "") == [(x,"")] Simon

3 5

"Free Setup" Now Available
by E-Computer Support 30 Oct '02

30 Oct '02

E-Computer Support: Hosting Made Easy ----------------------------------------------------------------------------------------------- This is a E-Computer Support special membership mailing! Please see the bottom of this mailing for subscription information. ------------------------------------------------------------------------------------------------- E-Computer Support can make it easy to switch hosts for less. Choose secure and reliable shared solutions priced just right for small and medium business. Hurry, offer ends 1/1/03. Check out our current E-Computer Support offerings below. Save $80-$100 when you sign up now for any E-Computer Support shared hosting solution. We'll do the set-up free. a.. Free Domain Transfers b.. All packages include e-mail support* c.. Check out all available packages, here To unsubscribe from these special newsletter mailings reply to this message with "R" in the subject.

1 0

Re: FW: Active Haskell development and libraries
by C.Reinke 29 Oct '02

29 Oct '02

[Mark] > I'm looking forward to reading the next communities and activities > report. me too!-) May I inject, though, that it has to be written before it can be read, and take this opportunity to invite all Haskellers to make sure their work/tool/group/etc. is covered? If it doesn't have a designated contact on our topics page, it probably isn't covered yet. And you don't want to be disappointed when you read the next edition, do you? Perhaps Mark and others may want to contribute brief descriptions of their situation, concerns, and wishes regarding the use of Haskell at their place of work?-) > In particular, I want to reassure myself that there is a lot of > useful actively-maintained stuff we can use, and more coming. Dear tool/library maintainers: Pending further developments, the HC&A report project pings are the best place to let the Haskell community as a whole know that your stuff is still alive and kicking (as opposed to a dust-gathering web link no longer pointing to stuff that once upon a time used to work)! > [libraries and tools page - what's alive, what combinations are > known to work, ..] I've often argued in the past that the page should be augmented by last-known-good information (probably one of the reasons why I was volunteered for the HC&A reports), so I definitely agree. And that centrally maintained link collections grow out of date is a fact of life on the web (people use them, but don't contribute updates). Let's see what we have: - the libraries and tools are out there - the list of libraries and tools is there, but needs dedicated maintenance, in addition to general haskell.org developments - John & Olaf have in the past been quite happy to give access to haskell.org to those willing to contribute there - the HC&A reports are meant to capture recent developments and current status of all things Haskell, thereby augmenting the longer term Haskell Central at haskell.org and what we need: - library and tool authors need to make their good work known (the twice-yearly HC&A reports are a minimum prompt for updates; more frequent updates in other form might be useful) - someone could ask John for access to haskell.org to keep an eye on just the libraries and tools page (adding the info Mark suggests; merging in info from announcements to haskell(a)haskell.org as well as from the twice-yearly HC&A reports; perhaps checking link validity once a month) > to avoid putting people off using Haskell, maybe the active and > currently-working things should be highlighted and easy to find > relative to the other things, right on the libraries and tools > page, given that currently there are a few broken links and > projects that are practically stalled, So there's an important contribution someone could make to the Haskell community as a whole! Making sure that the libraries and tools page on haskell.org remains a welcoming and useful front door representing the state of Haskell software development. Any takers? > and partly I'm wanting to see what other people think about where > Haskell is now relative to things like O'Caml from the point of > view of commercial instead of research users. At least, am I right > in thinking that more industrial Haskell users are wanted, and > that it's not meant to be solely an interesting piece of research? Don't know enough about O'Caml use to compare, but Haskell *is* being used in industry, some Haskell consultancy is available as well. We don't want to force people to use Haskell, but those who want to (and find the tools they need), do. It's just not easy to get those Haskellers to spend a few minutes to explain their use of their secret weapon to the rest of us. ] Yes, I'm probably talking about you, dear reader - why not ] contribute a brief summary about your commercial or industrial ] use of Haskell to the upcoming November edition of the HC&A ] report?-] Just get in touch with me over the next couple of ] days, please. [Manuel] > You surely have a point here. IMHO what is needed is a system > that allows library, tool, etc maintainers to add, edit, and > delete entries themselves. If these entries are annotated with > the date of the last update, it also becomes easier to gauge > whether a project is still alive. An automatic system might even > test for stale links and remove or mark them. Interesting suggestion, and generally I agree that distributed maintenance is a good thing. But experience has shown that one cannot expect a Haskeller to write useful tools _and_ be willing to talk about them at the same time (people don't even update their own web pages unless you ask them to..). If there is such a system, it would be worth trying it, but I'm not too optimistic - Haskellers need to be chased occasionally (demand-driven lazy evaluation:). Also, someone would need to hand out authorisations, unless you want to try a completely open system like a wiki, which I wouldn't recommend for this particular purpose (it's fine for many other purposes, though, before people start flaming!-). If we want additional organisation on the libraries and tools page, we need an additional organiser/maintainer, just focusing on this part. He/she can then try to move some work to the software authors. > An alternative to set up our own system would be to use an > existing one; eg, freshmeat.com. There's a unix/linux bias on that particular one, and I dislike software that only works on linux as much as software that only works on windows. Such limited software rarely stems from evil motivations, but often from a limited world-view of the developers (if they were truly cross-platform, they wouldn't have to single out unix/linux). ..index of Unix and cross-platform software, themes and related "eye-candy", and Palm OS software .. On May 1st 2002 freshmeat.net incorporated the contents of themes.org (originally founded and run by Trae "OctobrX" McCombs) into its database to further advance its services for the Linux community. Also, knowing that you can find everything Haskell on haskell.org is nice (and was a step forward from the situation before that). Doesn't mean that Haskell software shouldn't be publicised on other sites as well.. > The nice side effect of this is that Haskell software, then, also > pops up in general language-independent searches on freshmeat. Indeed. Cheers, Claus -- Haskell Communities and Activities Report (November 2002 edition) All contributions are due in by the end of October! http://www.haskell.org/communities/

1 0

Re: Haskell Online Bibliography
by C.Reinke 29 Oct '02

29 Oct '02

> An Online Bibliography of Haskell Research > http://haskell.readscheme.org/index.html > > I didn't see this announced; sorry if I missed it and this is a duplicate. I was announced. But that doesn't mean it shouldn't be publicised again, or that Haskellers shouldn't be invited to add references to their research publications there by emailing Jim. > Kudos to Jim Bender for a nice site! Indeed. Let's keep it useful by helping him with updates? Let me also point out (for no particular reason:) that it was mentioned in the May 2002 edition of the HC&A report, which apparently not all Haskellers have noticed yet?-) Cheers, Claus -- Haskell Communities and Activities Report (November 2002 edition) All contributions are due in by the end of October! http://www.haskell.org/communities/

1 0

Re: class Function ?
by Ashley Yakeley 29 Oct '02

29 Oct '02

At 2002-10-29 03:42, Jon Fairbairn wrote: >But we could just make $ the primitive instead of >juxtaposition (and infix the primary form). > >Then f a is shorthand for f $ a and it stops there. But then how would you overload $? -- Ashley Yakeley, Seattle WA

2 1

Re: class Function ?
by Ashley Yakeley 29 Oct '02

29 Oct '02

At 2002-10-29 02:43, Josef Svenningsson wrote: >> I'm pretty sure it's not possible... >> >You mean in H98? Sure no! What I meant was to implement overloading of >function application as an extension of H98. See my earlier message. If function application is overloadable, then there must be some operator "funapp" that corresponds to it. But operators themselves need function application, so you end up with: f a reduces to funapp f a reduces to funapp (funapp (funapp f)) a reduces to etc. -- Ashley Yakeley, Seattle WA

3 2