- Haskell-Cafe - Haskell.org

ANN: atom-0.1.4
by Tom Hawkins 16 Dec '09

16 Dec '09

A bug fix affecting floating point variable initialization. http://hackage.haskell.org/package/atom

1 0

Status of Haskell Platform for Snow Leopard
by R J 16 Dec '09

16 Dec '09

Could someone provide the status and expected release date of the Haskell Platform for Snow Leopard (Mac OS X 10.6.2)? Thanks. _________________________________________________________________ Your E-mail and More On-the-Go. Get Windows Live Hotmail Free. http://clk.atdmt.com/GBL/go/171222985/direct/01/

2 1

Token parsers in parsec consume trailing whitespace
by Edward Z. Yang 15 Dec '09

15 Dec '09

I recently ran into a nasty little bug where token parsers in parsec consume trailing whitespace, which were consuming newlines and thus bamboozling a higher-level "sepBy" combinator. I replaced my instances of 'natural' with 'read <$> many1 digit', but this gave rise to the following questions: 1. Is there a more elegant way of doing number parsing? In particular, are there token parsers that don't consume trailing whitespace, or is there a better way to do this with the primitives. 2. It seems that the "token" approach of parsing lends itself to a different style of parsing than the one I'm doing, namely, instead of assuming all of your parsers consume exactly what they need, and no more, you assume that they consume what they need and spaces. Thus, code that looks like: do foo <- fooParser spaces bar <- barParser spaces baz <- bazParser return $ FooBarBaz foo bar baz becomes: FooBarBaz <$> fooParser <*> barParser <*> bazParser And instead of using sepBy you just use many. One of the problems I see with this approach is if I was using sepBy newline, the new token oriented parser has no way of distinguishing "foo bar baz\nfoo bar baz" from "foo bar baz foo bar baz", which is something I might want to care about. Which method do you prefer? 3. Not so much a question as a comment: when parsing entire files, be sure to add the eof combinator at the end! Cheers, Edward

2 2

(semi OT) Fwd: Old math reveals new thinking in children's cognitive development
by Brandon S. Allbery KF8NH 15 Dec '09

15 Dec '09

Begin forwarded message: > Date: December 11, 2009 8:00:00 PM EST > Subject: Old math reveals new thinking in children's cognitive > development > Source: ScienceDaily: Latest Science News > > Five-year-olds can reason about the world from multiple perspectives > simultaneously, according to a new theory by researchers in Japan > and Australia. Using an established branch of mathematics called > Category Theory, the researchers explain why specific reasoning > skills develop in children at certain ages, particularly at age > five. The new theory shows that these reasoning skills have similar > profiles of development because they involve related sorts of > processes. > Read more… > Unexpected applications of category theory for $500, Alex.... -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery(a)kf8nh.com system administrator [openafs,heimdal,too many hats] allbery(a)ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

3 2

Re: [Haskell-cafe] Re: Re: Allowing hyphens in identifiers
by Colin Paul Adams 15 Dec '09

15 Dec '09

>>>>> "Richard" == Richard O'Keefe <ok(a)cs.otago.ac.nz> writes: Richard> The real point is that the revised version, with command Richard> line arguments and all, is still just 52 SLOC. (41 if Richard> you don't count type specifications the compiler could Richard> have inferred or the two import directives.) This looks really good. When I first started writing Haskell seriously, just over a year ago, I wrote with underscores, but the mix of style caused by the standard library names was so disconcerting that IReluctantlySwitchedToHumpyIlliterateStyle (though not for comments, where I stuck to standard English punctuation). So I welcome this chance to switch to natural English style (hyphens). The main that puzzles me at the moment is how to write a cabal file. That is, I can specify the ghc options to invoke the preprocessor in the cabal file, but this supposes the compiled program is available on the system concerned. This won't necessarily be the case if I distribute code written in this style on hackage. So the answer seems to be to release this preprocessor on hackage, and then make it a dependcy. But can a library depend upon an executable program? looking at the Cabal users guide, I can't see anywhere that says it can't. -- Colin Adams Preston Lancashire

1 0

Fwd: [Haskell-cafe] Boxed Mutable Arrays
by Alberto G. Corona 15 Dec '09

15 Dec '09

---------- Forwarded message ---------- From: Alberto G. Corona <agocorona(a)gmail.com> Date: 2009/12/15 Subject: Re: [Haskell-cafe] Boxed Mutable Arrays To: Daniel Peebles <pumpkingod(a)gmail.com> Ok, so the state content is not accessible. Nice. 2009/12/15 Daniel Peebles <pumpkingod(a)gmail.com> No, they are actually being mutated. ST is basically IO with a > universal state thread (IO uses RealWorld) to prevent you from letting > any of the mutable structures out (or any in) of the block. The whole > point of ST is to have real mutable references/arrays that have a > referentially transparent if you look at them from outside. > > Dan > > On Tue, Dec 15, 2009 at 9:23 AM, Alberto G. Corona <agocorona(a)gmail.com> > wrote: > > AFAIK, ST Arrays are pure data structures. They are not really mutable. > They > > are destroyed and recreated on every update. The mutation is just > simulated > > thanks to the hidden state in the state monad. Sure, the garbage > collector > > must have a hard work in recycling all the "backbones" of the discarded > > arrays (not the elements). > > > > 2009/12/14 Brad Larsen <brad.larsen(a)gmail.com> > >> > >> Is anyone working on fixing ticket #650 > >> <http://hackage.haskell.org/trac/ghc/ticket/650>? In short, STArray > >> and the garbage collector don't play well together, resulting in array > >> updates being non-constant time operations. This bug makes it very > >> difficult/impossible to write efficient array algorithms that depend > >> upon mutation in Haskell. > >> > >> On another note, does this (or perhaps better phrased, will this) bug > >> also affect Data Parallel Haskell? > >> > >> I would really like to see highly efficient, mutable, boxed arrays in > >> Haskell! Unfortunately, I don't have the know-how to fix Ticket 650. > >> > >> Sincerely, > >> Brad > >> _______________________________________________ > >> Haskell-Cafe mailing list > >> Haskell-Cafe(a)haskell.org > >> http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe(a)haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > >

1 0

writing graphs with do-notation
by Soenke Hahn 15 Dec '09

15 Dec '09

Hi! Some time ago, i needed to write down graphs in Haskell. I wanted to be able to write them down without to much noise, to make them easily maintainable. I came up with a way to define graphs using monads and the do notation. I thought this might be interesting to someone, so i wrote a small script to illustrate the idea. Here's an example: example :: Graph String example = buildGraph $ do a <- mkNode "A" [] b <- mkNode "B" [a] mkNode "C" [a, b] In this graph there are three nodes identified by ["A", "B", "C"] and three edges ([("A", "B"), ("A", "C"), ("B", "C")]). Think of the variables a and b as outputs of the nodes "A" and "B". Note that each node identifier needs to be mentioned only once. Also the definition of edges (references to other nodes via the outputs) can be checked at compile time. The attachment is a little script that defines a Graph-type (nothing elaborate), the "buildGraph" function and an example graph that is a little more complex than the above. The main function of the script prints the example graph to stdout to be read by dot (or similar). By the way, it is possible to define cyclic graphs using mdo (RecursiveDo). I haven't come across something similar, so i thought, i'd share it. What do you think? Sönke

5 5

ForSyDe (parameterized-data) fails to build
by Dominic Steinitz 15 Dec '09

15 Dec '09

I'm not sure how actively this is maintained or used but I couldn't get it to build. Downloading parameterized-data-0.1.3... Configuring parameterized-data-0.1.3... Preprocessing library parameterized-data-0.1.3... Building parameterized-data-0.1.3... src\Data\Param\FSVec.hs:1:46: Warning: -XPatternSignatures is deprecated: use -XScopedTypeVariables or pragma {-# LANGUAGE Sco pedTypeVariables#-} instead src\Data\Param\FSVec.hs:462:0: warning: no newline at end of file [1 of 2] Compiling Data.Param.FSVec ( src\Data\Param\FSVec.hs, dist\build\Data\Param\FSVec.o ) src\Data\Param\FSVec.hs:103:22: Couldn't match expected type `t -> ExpQ' against inferred type `FSVec s a1' In the expression: (readFSVec str) (lift :: (Nat s, Lift a) => FSVec s a -> ExpQ) In the expression: ((readFSVec str) (lift :: (Nat s, Lift a) => FSVec s a -> ExpQ), undefined) In the definition of `parseFSVecExp': parseFSVecExp str = ((readFSVec str) (lift :: (Nat s, Lift a) => FSVec s a -> ExpQ), undefined) cabal.exe: Error: some packages failed to install: ForSyDe-3.0 depends on parameterized-data-0.1.3 which failed to install. parameterized-data-0.1.3 failed during the building phase. The exception was: exit: ExitFailure 1

1 0

ANNOUNCE: explicit-iomodes-0.1
by Bas van Dijk 15 Dec '09

15 Dec '09

Hello, I just released the small package explicit-iomodes-0.1: http://hackage.haskell.org/package/explicit-iomodes-0.1 It's a wrapper around System.IO that provides a Handle type which is parametrized with the IOMode it is in. All operations on handles specify the needed IOMode which makes it a type error if you read from a write-only handle or if you write to a read-only handle for example. Thanks to Lee Houghton, Brandon S. Allbery and Jason Dagit for providing initial feedback! regards, Bas

1 1

Yay 6.12.1!
by Evan Laforge 15 Dec '09

15 Dec '09

So far, this new release has let me remove: - The new "Import of xyz is redundant" warning pointed out tons of cruft in my imports: 117 of them! Apparently it's better than the 6.10 algorithm. It's amazing how much cruft builds up in import lists over time even with -Wall. One issue is that I can still get a spurious warning from it: if I have 'import qualified Text.Read as Read' and then have some Read instances, it will think the import is redundant even though it won't compile without it (`readPrec' is not a (visible) method of class `Read'). The interesting thing is that even though I'm importing it qualified, I write the readPrec in the instance without qualification since 'instance Read X where Read.readPrec = ...' is not allowed. So maybe ghc is confused by that since it doesn't see a Read. anywhere. Importing unqualified doesn't make the warning. - I removed {-# OPTIONS_GHC -fno-warn-unused-imports #-} from a lot of files, now that the bugs that make spurious import warns are fixed. And the bogus warnings with view patterns are gone. - I removed a local version of Data.Map, now that toDescList is in. - Passing -I/path/to/ghc/include to hsc2hs to get it to include HsFFI.h seems to no longer be necessary. - The warnings "-#include is deprecated: No longer has any effect" are not quite right, because they are reuired by hsc2hs, and in fact hsc2hs is inserting {-# INCLUDE "c_interface.h" #-}. Maybe it should be updated to not do that? I know these are small improvements and not as cool as faster parallelism, but I want so say that these little fixes are noticed and much appreciated, and give a big thank you to the Simons and Ian and anyone else involved with this release. It's so satisfying to finally see a warning free compile!

1 0