January 2007 - Haskell-Cafe

newTArrayIO
by Chad Scherrer 26 Jan '07

26 Jan '07

This seems like a natural thing to have around, but it's not in GHC 6.6... newTArrayIO :: (Enum i, Ix i) => (i, i) -> a -> IO (TArray i a) newTArrayIO (a,b) = liftM (TArray . listArray (a,b)) . sequence . zipWith ignore [a..b] . repeat . newTVarIO where ignore = flip const I haven't done any testing with this beyond type checking, but it seems like it could be useful for similar cases to newTVarIO. Has anyone else played with anything similar? -- Chad Scherrer "Time flies like an arrow; fruit flies like a banana" -- Groucho Marx

2 2

Re: [Haskell] FW: A history of Haskell
by Justin Bailey 26 Jan '07

26 Jan '07

On 1/25/07, Simon Peyton-Jones <simonpj(a)microsoft.com> wrote: > Many of you will know that Paul Hudak, John Hughes, Phil Wadler and I have been working on a paper called > > A History of Haskell: being lazy with class > Just wanted to say this paper is excellent, and actually a great tool for learning Haskell. I read it about 2 months after I'd been introduced to Haskell, and it made quite a few things about the language clear to me. It's clearly not a tutorial, but somehow knowing parts of the history made the language clearer. Thanks for your (and all the other authors') effort! Justin

1 0

GHC concurrency runtime "breaks" every 497 (and a bit) days
by Neil Davies 26 Jan '07

26 Jan '07

In investigating ways of getting less jitter in the GHC concurrency runtime I've found the following issue: The GHC concurrency model does all of its time calculations in "ticks" - a tick being fixed at 1/50th of a second. It performs all of these calculations in terms the number of these ticks since the Unix epoch (Jan 1970). Which is stored as an Int - unfortunately this 2^31 bits overflows every 497 (and a bit) days. When it does overflow any threads on the timer queue will either a) run immediately or b) not be run for another 497 days - depending on which way the sign changes. Also any timer calculation that spans the wrapround will not be dealt with correctly. Although this doesn't happen often (the last one was around Sat Sep 30 18:32:51 UTC 2006 and the next one will not be until Sat Feb 9 21:00:44 UTC 2008) I don't think we can leave this sort of issue in the run-time system. Take a look at the definition of getTicksofDay (in base/include/HsBase.h (non-windows) / base/cbits/Win32Utils.c) and getDelay (in base/GHC/Conc.lhs) to understand the details of the issue. I don't mind having a go at the base system to remove this problem - but before I do I would like to canvas some opinions. I'll do that in a separate thread. Neil

3 3

No Derived Read for Unboxed Arrays
by Matthew Bromberg 25 Jan '07

25 Jan '07

I was trying to convert some code from ordinary boxed array to unboxed arrays for performance reasons. Presumably the conversion, according to the GHC documentation should only involve appropriate type signatures (e.g. using UArray instead of Array) and importing Data.Array.Unboxed. However my code ultimately failed because I load a large array saved as a text file using the derived Read, Show mechanism. For some reason there is no Read function for unboxed arrays. Here is a little GHCI session showing the problem: Prelude> :m Data.Array.Unboxed Prelude Data.Array.Unboxed> let e = listArray (0,3) [0 .. 3] :: UArray Int Int Prelude Data.Array.Unboxed> let se = show e Prelude Data.Array.Unboxed> se "array (0,3) [(0,0),(1,1),(2,2),(3,3)]" Prelude Data.Array.Unboxed> let e2 = read se :: UArray Int Int <interactive>:1:9: No instance for (Read (UArray Int Int)) arising from use of `read' at <interactive>:1:9-15 Possible fix: add an instance declaration for (Read (UArray Int Int)) In the expression: read se In the expression: read se :: UArray Int Int In the definition of `e2': e2 = read se :: UArray Int Int However if I try to read it in as boxed arrays, no problem: Prelude Data.Array.Unboxed> let e2 = read se :: Array Int Int Prelude Data.Array.Unboxed> e2 array (0,3) [(0,0),(1,1),(2,2),(3,3)] Is there a reason why this doesn't work? Is it a design choice or does it merely reflect the fact that no one has gotten around to writing a read function for unboxed arrays. I imagine it would be trivial to fix this however.

4 6

Re: [Haskell-cafe] A function for Maybes (RESOLVED)
by John Ky 25 Jan '07

25 Jan '07

Thanks -John On 1/26/07, Brandon S. Allbery KF8NH <allbery(a)ece.cmu.edu> wrote: > > > On Jan 25, 2007, at 9:15 , John Ky wrote: > > > Is there a built-in function that already does this? > > > > foo :: (a -> b) -> Maybe a -> Maybe b > > foo f m > > | isNothing m = Nothing > > | otherwise = Just (f (fromJust m)) > > Nothing specific to Maybe, because the more general liftM (over > monads) or fmap (over functors) already does it. > > -- > brandon s. allbery [linux,solaris,freebsd,perl] allbery(a)kf8nh.com > system administrator [openafs,heimdal,too many hats] allbery(a)ece.cmu.edu > electrical and computer engineering, carnegie mellon university KF8NH > > > >

1 0

Re: [Haskell-cafe] No Derived Read for Unboxed Arrays
by dons＠cse.unsw.edu.au 25 Jan '07

25 Jan '07

ndmitchell: > HI Don > > >> (But of course, having Read/Show defined for UArray may well be > >> useful, and sounds a good idea) > > > >There's also an instance Binary for UArray. That might be useful? > > Is there an instance Binary in a released library? If in doubt, look on hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/binary/0.2 -- Don

1 0

A function for Maybes
by John Ky 25 Jan '07

25 Jan '07

Is there a built-in function that already does this? foo :: (a -> b) -> Maybe a -> Maybe b foo f m | isNothing m = Nothing | otherwise = Just (f (fromJust m)) *Main> foo (+2) (Just 3) Just 5 *Main> foo (+2) Nothing Nothing If so what is it? If not, what should I call it? Thanks -John

6 5

Monomorphism restriction
by Marco Túlio Gontijo e Silva 25 Jan '07

25 Jan '07

Hello, I talked for a while with bd_ about this on #haskell, and I think maybe I'm just being silly. But I can't get why: > lambda = \x -> length (show x) or > dot = length . show is different from > pre x = length $ show x I read about monomorphism restriction on the haskell 98 report, but I couldn't find where it explains the reason why these different versions influence on type infer. Thanks for any help. -- malebria Marco Túlio Gontijo e Silva Correio (MSN): malebria(a)riseup.net Jabber (GTalk): malebria(a)jabber.org Ekiga: malebria(a)ekiga.net IRC: malebria(a)irc.freenode.net malebria(a)irc.oftc.org Skype: marcotmarcot Telefone: 33346720 Celular: 98116720 Endereço: Rua Paula Cândido, 257/201 Gutierrez 30430-260 Belo Horizonte/MG Brasil

4 5

Re: [Haskell-cafe] IO is not a monad
by Yitzchak Gale 25 Jan '07

25 Jan '07

Scott Turner wrote: > Paul B. Levy's studies of "call-by-push-value" model strictness/laziness using > a category theoretic approach. That sounds interesting. Do you have a reference for that? Thanks, Yitz

2 1

basic field questions
by jamin1001 25 Jan '07

25 Jan '07

Hi, I am new at Haskell and have some basic questions. Is there any way to do this more effectively? This causes the GHC compile error "Multiple declarations of Main.test": data A = A {test :: Int} data B = B {test :: Int} The Haskell 98 report in 4.2.1 under Labelled Fields says "A label cannot be shared by more than one type in scope. Field names share the top level namespace with ordinary variables and class methods and must not conflict with other top level names in scope." So then how should this be done? What if I want to do something like data Chair = Chair {pos:: Int, color :: Int} data Table = Table {pos:: Int, color :: Int} Also, could someone tell me why this doesn't compile in GHC: data Test = A {a::Int} | B {a::Int, b::Int} data Test2 = C {c::A} (Test2 line): Not in scope: type constructor or class 'A' Is there a way to qualify identical field names? What are some standard practices for dealing with this? Thanks, Jamin Ohmoto-Frederick -- View this message in context: http://www.nabble.com/basic-field-questions-tf3080392.html#a8558522 Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

7 10