- Haskell - Haskell.org

Haskell Workshop Steering Committee
by Johan Jeuring 02 Nov '05

02 Nov '05

At the Haskell workshop in Tallinn in September it was decided to set up a Haskell Workshop Steering Committee. The main purpose of the Haskell Workshop Steering Committee is to provide continuity of the workshop and to offer help and advice to the current organizer(s) of the workshop. I'm pleased to announce the Haskell Workshop Steering Committee, which has been approved by ACM SIGPLAN. You can find more information about the Haskell Workshop and its Steering Committee on http://www.haskell.org/haskell-workshop/ -- Johan Jeuring

1 0

RE: specification of sum
by Scherrer, Chad 02 Nov '05

02 Nov '05

> The solution would be to bring 'sum' and 'product' into the Num class so > the most efficient version for each type can be used and the default is > no worse than the current non-class versions. (this is even pretty much > completly backwards compatable so could be considered for haskell 06) > > I'd also like to see 'join' and 'ap' added to Monad while we are at it. > > John Ooo, that's much better. I'll retract my sum' suggestion in that case.

1 0

specification of sum
by Scherrer, Chad 02 Nov '05

02 Nov '05

I was wondering... In my experience, it's worked much better to use sum' = foldl' (+) 0 than the built-in "sum" function, which leaks memory like crazy for large input lists. I'm guessing the built-in definition is sum = foldr (+) 0 But as far as I know, (+) is always strict, so foldl' seems much more natural to me. Is there a case where the build-in definition is preferable? Chad Scherrer Computational Mathematics Group Pacific Northwest National Laboratory "Time flies like an arrow; fruit flies like a banana." -- Groucho Marx

5 7

RE: [Haskell] specification of sum
by Scherrer, Chad 02 Nov '05

02 Nov '05

> > You don't always want (+) to be strict. Consider working with > the ring of formal power series over, say, the integers. You > don't want (+) to force the evaluation of an infinite formal > summation which is passed to it, since that's an infinite > loop, so it will have to be non-strict, somewhat like zipWith > (+) over the lists of coefficients. > > - Cale Hmm, this is a good point, but for most people, It seems like the most common usage would be to add up a list of actual concrete numbers, and the resulting memory leak in the code using sum is at least a minor annoyance. It's hard to say how much time a given newbie will take to catch this nuance. Since sum' = foldl' (+) 0 (like foldl', the ' means "strict" ) is so often preferable, I'll go so far as to suggest it be included it in upcoming versions of Data.List. That way it would be hard to miss, and would remove what could otherwise be a very common stumbling block for anyone doing numerical work with Haskell. I haven't used product so extensively, but I suspect there may be similar issues with it? -Chad

1 0

ANNOUNCE: Frown - an LALR(k) Parser Generator for Haskell (version 0.6, beta)
by Ralf Hinze 01 Nov '05

01 Nov '05

I'm pleased to announce the first release of Frown (version 0.6, andromeda release), an LALR(k) Parser Generator for Haskell 98. This is a beta quality release. Frown's salient features are: o The generated parsers are time and space efficient. On the downside, the parsers are quite large. o Frown generates four different types of parsers. As a common characteristic, the parsers are genuinely functional (ie `table-free'); the states of the underlying LR automaton are encoded as mutually recursive functions. Three output formats use a typed stack representation, one format due to Ross Paterson (code=stackless) works even without a stack. o Encoding states as functions means that each state can be treated individually as opposed to a table driven-approach, which necessitates a uniform treatment of states. For instance, look-ahead is only used when necessary to resolve conflicts. o Frown comes with debugging and tracing facilities; the standard output format due to Doaitse Swierstra (code=standard) may be useful for teaching LR parsing. o Common grammatical patterns such as repetition of symbols can be captured using rule schemata. There are several predefined rule schemata. o Terminal symbols are arbitrary variable-free Haskell patterns or guards. Both terminal and nonterminal symbols may have an arbitrary number of synthesized attributes. o Frown comes with extensive documentation; several example grammars are included. Furthermore, Frown supports the use of monadic lexers, monadic semantic actions, precedences and associativity, the generation of backtracking parsers, multiple start symbols, error reporting and a weak form of error correction. Frown is available in source form, which can be compiled with GHC version 5.02+. The source code and further information is available on the Frown home page http://www.informatik.uni-bonn.de/~ralf/frown/index.html Please send any bug reports and comments to ralf(a)informatik.uni-bonn.de. Happy frowning, Ralf

1 0

Haskell Weekly News: November 1, 2005
by John Goerzen 01 Nov '05

01 Nov '05

Haskell Weekly News: November 1, 2005 Greetings, and thanks for reading the 13th issue of HWN, a weekly newsletter for the Haskell community. Each Tuesday, new editions will be posted (as text) to [1]the Haskell mailing list and (as HTML) to [2]The Haskell Sequence. 1. http://www.haskell.org/mailman/listinfo/haskell 2. http://sequence.complete.org/ New Releases * Time Library 0.2. Ashley Yakeley [3]announced a draft of a new time library and solicited comments. 3. http://thread.gmane.org/gmane.comp.lang.haskell.libraries/3882 Calls for participation HCAR entries due TODAY. Andres Loeh posted a [4]reminder that entries for the Haskell Communities and Activities Report are due today. 4. http://article.gmane.org/gmane.comp.lang.haskell.cafe/8876 Discussion Undecidable instances. In a [5]thread about the need for undecidable instances, Johannes Waldmann [6]suggested the use of termination analyzers. 5. http://thread.gmane.org/gmane.comp.lang.haskell.general/12334 6. http://article.gmane.org/gmane.comp.lang.haskell.general/12343 Finding the character frequency in a string. Jon Fairbairn started an interesting [7]thread about calculating the frequency each character in a string occurs. 7. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/8869 FFI and modifying Haskell memory. Joel Reymont [8]asked about proper FFI design for programs that read data in. 8. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/8834 Haskell Toolchain GHC assembly. John Meacham [9]posted an analysis of GHC's assembly output, a comparison to jhc, and some suggestions for improving GHC's output. 9. http://thread.gmane.org/gmane.comp.lang.haskell.glasgow.user/8827 Data.* collections maintenance. This large [10]thread on the libraries list covered potential future directions for the Data.* libraries. 10. http://thread.gmane.org/gmane.comp.lang.haskell.libraries/3813 Quotes of the Week For those that adhere to learn one new language per year which other languages should we learn? Matz suggests io (or Haskell but he admits it makes his brain explode). -- From RubyConf 2005 Roundtable discussion with Yukihiro "Matz" Matsumoto, creator of Ruby. The Meta-FAQ Q: What happened to HWN last week? A: The answer to this question really goes back to the 16th century and the first movements in Europe to modernize astronomy away from the earth-centric view. But it wasn't really until Newton's time (late 17th and early 18th centuries) that we started to have the more advanced understanding necessary to begin answering this question. Modern astronomers have been able to calculate the period of the earth at 86164.09053 seconds, which is a few minutes shorter than the apparent day due to the earth's simultaneous orbit around the sun. The second part of the answer to this question dates back even farther to ancient Egypt. The Egyptians used a duo-decimal numbering system, and found it convenient to separate each day into 24 equal units. Since then, other definitions for the hour have come in to play, usually based on the apparent solar day or the time between sunrise and sunset. These days, the hour is defined at 3600 seconds. While each day appears to consist of approximately 24 hours, the period of the earth really is 23 hours, 56 minutes, and 4.09053 seconds. (I for one am pleased to receive the extra 4 minutes per day.) So, we can see that the problem really is that there just weren't enough hours in a day for your HWN editor to get the issue out on time last week. I blame it on the ancient Egyptians. Q: Would HWN have come out on time if you hadn't had to prepare a lengthy explanation for why it was late? A: Good question. You should medidate on that for awhile and let us know for next week's HWN. Q: Does this issue cover two weeks of fascinating Haskell news then? A: Of course! About Haskell Weekly News Thanks to Jim Apple and Josef Svenningsson for contributing to this week's HWN. Want to continue reading HWN? Please help us create new editions of this newsletter. Please see the [11]contributing information, or send stories to hwn -at- complete -dot- org. There is also a Darcs repository available. 11. http://sequence.complete.org/hwn-contrib

1 0

haskell logo for webmasters
by xah lee 01 Nov '05

01 Nov '05

i created two haskell logos for websites to spread Haskell. http://xahlee.org/haskell/haskell-logo.html it's in public domain. suggestions welcome. Thanks. Xah xah(a)xahlee.org ∑ http://xahlee.org/ ☄

1 0

Writing large n-dim un-boxed array of Int32 quickly?
by Rene de Visser 31 Oct '05

31 Oct '05

Hello, I want to write a multi-dimensional unboxed arrary of Int32 to a file. (And also read it back later). What I tried so far is import NewBinary.Binary ... mapM_ (put bin) $ elems array ... but this was exceedlying slow. The array contains about 10 000 000 entries. Any suggestions? Rene.

4 5

Monads vs. continuations
by Gregory Woodhouse 31 Oct '05

31 Oct '05

Newbie alert: I have some superficial familiarity with continuations as they occur in traditional denotational semantics, but certainly not a deep understanding. I also have a special interest in distributed and/or concurrent processing, so it only seemed natural to me that the monad concept was one I'd want to confront head on. Now, I warn you: I am quite new to Haskell (though I have some prior exposure to Scheme and a background in mathematics). Now, I've just started reading through Thompson's text and came across this example: goUntilEmpty :: IO () goUntilEmpty = do line <- getLine if (line == []) then return () else (do putStrLn line goUntilEmpty) Okay, this seems sensible enough. Loosely speaking, I see this code as getting a line, checking to see if it's empty. If it is, it just quits (returning the "empty" value). Otherwise, it prints line, and invokes itself through a *new* do statement. That seems awfully like using a continuation to track the input stream as part of the environment. But it seems obvious to me that here is something I'm not understanding here. I think of the do as providing an appropriate continuation (one in which the line just read is gone) to pass to the next call. Okay, maybe I'm taking things a bit too literally here, but I seem to recall that a monad is an algebraic object with right and left identity and an associative composition. I understand the monad here takes a value (()) and returns an object IO (), and do becomes a functor of sorts, taking ordinary functions and mapping them to new functions having their codomain in a new category (an instance of a monad?) This is where it seems to me that I must be getting the terminology wrong. Can someone help me out here? === Gregory Woodhouse gregory.woodhouse(a)sbcglobal.net "The most incomprehensible thing about the world is that it is at all comprehensible." --Albert Einstein (1879-1955)

4 5

RE: [Haskell] really undecidable instances?
by Simon Peyton-Jones 30 Oct '05

30 Oct '05

This one can't. But it's hard to formulate a general rule. -fallow-undecidable-instances simply says that you, the programmer, take responsibility for termination. Without the flag, GHC uses a simple but sometimes over-conservative rule Simon | -----Original Message----- | From: haskell-bounces(a)haskell.org [mailto:haskell-bounces@haskell.org] On Behalf Of Wolfgang | Jeltsch | Sent: 17 October 2005 14:17 | To: Haskell ML | Subject: [Haskell] really undecidable instances? | | Hello, | | what ist the problem with instance declarations like the following: | | instance C Int a => D Char [a] | | Why are such declarations only allowed with -fallow-undecidable-instances in | GHC? How can they result in undecidability? | | Best wishes, | Wolfgang | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell

4 4