- Haskell-Cafe - Haskell.org

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

26 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 26 Jan '07

26 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

class question
by Hans van Thiel 24 Jan '07

24 Jan '07

Hello, I'm trying to understand classes and defined: class Monoid a where e :: a add :: a -> a -> a add a e = a add e a = a instance Monoid a Int where e = 0 add x y = x + y This works just fine, also for instance definitions of Char, Bool and lists. But defining: class (Num a, Monoid a) => NumMon a where e = 0 add x y = x + y reults in error messages. -- Hugs: ERROR "Chap12.hs":57 - No member "e" in class "NumMon" -- GHCi: Chap12.hs:58:3: `add' is not a (visible) method of class NumMon' I've also tried instance definitions of NumMon (leaving out 'where' and what's next in the class declaration) and get similar messages. The definition of NumMon by itself, just the first line, is accepted by Hugs and GHCi both. What am I doing wrong? Many thanks in advance. Hans van Thiel

3 5

Re: [Haskell-cafe] Strings in Haskell
by Bryan Donlan 24 Jan '07

24 Jan '07

Neil Mitchell wrote: > Hi Alexy, > >> Now I'm reading a >> Haskell book which states the same. Is there a more efficient Haskell >> string-handling method? Which functional language is the most >> suitable for text processing? > > There are the Data.ByteString things, which are great, and have much > less overhead. > > But remember that Haskell is lazy. If you are thinking "well I have to > process a 50Mb file", remember that Haskell will lazily read and > process this file, which substantially reduces the memory requirements > so only a small portion will ever be in memory at a time. Or you can get the best of both worlds by using Data.ByteString.Lazy :) Even with laziness, all the indirections that String causes hurts performance.

3 2

small step evaluation as an unfold?
by Steve Downey 24 Jan '07

24 Jan '07

(overall context - working through TaPL on my own, reimplemnting typecheckers in haskell) the type checkers all follow the same pattern, in ocaml they throw an exception when the small step fails, which may mean taking another branch in the eval, but that that sub expression has hit bottom. it is self admittedly not good ocaml, and it seems to be even worse haskell, as i try to extend the simple evaluator i have to deal with managing reporting errors. having the single small step evaluator return a Maybe is fairly close. then the evaluator above it just bottoms out when eval1 expr returns Nothing, by passing expr back up as the result. but it occurs to me that it might be better to express it as an unfold, where the result is a list with the last element as the irresucible expression. or am i insane / intoxicated ?

2 2

Re: small step evaluation as an unfold?
by Steve Downey 24 Jan '07

24 Jan '07

good, it felt like something that might have occurred to someone before. On 1/23/07, Nicolas Frisby <nicolas.frisby(a)gmail.com> wrote: > Jeremy Gibbons thought of it; that's good company ;) > > http://portal.acm.org/citation.cfm?id=289457 > > > > On 1/23/07, Steve Downey <sdowney(a)gmail.com> wrote: > > (overall context - working through TaPL on my own, reimplemnting > > typecheckers in haskell) > > the type checkers all follow the same pattern, in ocaml they throw an > > exception when the small step fails, which may mean taking another > > branch in the eval, but that that sub expression has hit bottom. > > > > it is self admittedly not good ocaml, and it seems to be even worse > > haskell, as i try to extend the simple evaluator i have to deal with > > managing reporting errors. > > > > having the single small step evaluator return a Maybe is fairly close. > > then the evaluator above it just bottoms out when eval1 expr returns > > Nothing, by passing expr back up as the result. > > > > but it occurs to me that it might be better to express it as an > > unfold, where the result is a list with the last element as the > > irresucible expression. > > > > or am i insane / intoxicated ? > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe(a)haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > >

1 0