February 2002 - Haskell-Cafe

Ground Up
by Jerry, JiJie 01 Mar '02

01 Mar '02

Good day everyone, I'm a haskell newbie trying to seeking advice to advance myself. My backgrounds are: * As a non-CS student, I have absolutely no knowledge of lambda calculus * And unfortunately I have to make painful decision on spending $30 on a book or three days' meal While my goals are: * Become a pragmatic haskell programmer in the shortest time * At the minimal expense What I have done for the past few weeks were: * I read almost all the free educational sources at www.haskell.org, * Subscribed to this mailing list and try to digest every mail * Read most of the "The Haskell School of Expression" (by Paul Hudak) and the non-theoretical chapters of the "An Introduction To Functional Programming Systems Using Haskell" (by AJT Davie), which are the only two introductory level haskell related books in our library However, my problems are: * I still don't understand most of the codes I found, like the various haskell libraries * I still have no clue of most (ok, almost all) of what is being discussed in this mailing list So I'm eager to know if there are cost-effective ways to achieve my goals or at least leverage myself from the beginner's level. Your advice would be greatly appreciated! Regards, Jerry

4 3

Changing a light bulb.
by Shawn P. Garbett 28 Feb '02

28 Feb '02

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Now after my earlier soap box tirade I'm trying to put my code where my mouth is. >>blush<< It's harder than I thought. I've broken it down into a State Model of a light bulb. The goal, to find out just how much Haskell code does it take to change the state of a light bulb? Here's a very crippled version. Is there an easy way to introduce state without changing the type of main??? I've written a much more complex example, but I got into things like main :: STT(IO) using a monad transformer. So really, the big question is, must I use a monad transformer? - ------------------------------------------------------------------------------------------------ - -- State model of a light bulb import Monad import IO main :: IO () main = do hSetBuffering stdin NoBuffering process process :: IO () process = do i <- assign initialState putChar '\n' print(s) if (s /= Exit) then process else return () data State = Dark | Light initialState :: State initialState = Dark data Stimulus = On | Off | Exit deriving (Show, Eq, Enum) charToStimulus :: Char -> Stimulus charToStimulus '1' = On charToStimulus '0' = Off charToStimulus c = Exit getStimulus :: IO Stimulus getStimulus = liftM charToStimulus getChar - -- State transformer newtype St a = MkSt (State -> (a, State)) - -- State transformer applied to state apply :: St a -> State -> (a, State) apply (MkSt f) s = f s - -- State monad instance Monad St where return x = MkSt f where f s = (x,s) p >>= q = MkSt f where f s = apply (q x) s' where (x, s') = apply p s - -- Useful State operations fetch :: St State fetch = MkSt f where f s = (s,s) assign :: State -> St () assign s' = MkSt f where f s = ((),s') done :: St () done = return () - ----------------------------------------------------------------------------------------------------------------------- - -- You're in a maze of twisty little statements, all alike. Public Key available from http://www.garbett.org/public-key -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8fqdpDtpPjAQxZ6ARAkCWAJ9pGcS/hQpoK12AdcEmt8Y/0rEv9ACfWGtO 1FL9VwopmgsAyUAv9RL++T8= =a9xu -----END PGP SIGNATURE-----

2 1

Re: Ground Up
by Rijk J. C. van Haaften 28 Feb '02

28 Feb '02

Jerry wrote >However, my problems are: >* I still don't understand most of the codes I found, like the various > haskell libraries Practice is the only answer to this problem, as Keith Wansbrough says. >* I still have no clue of most (ok, almost all) of what is being > discussed in this mailing list Though I am a CS student, being highly interested in Haskell and practising a lot, I didn't understand most of the discussions on this mailing list. I started understanding them only after I got involved in implementing a Haskell compiler. Therefore, don't worry about this point. A haskell-user doesn't need to know the details of the haskell compiler ins and outs. Rijk-Jan van Haaften

4 4

Re: Help
by Rijk J. C. van Haaften 28 Feb '02

28 Feb '02

You probably want to do something like this: main = do { contents <- input "twoboxes.dat" return (control (parser contents)) } At 11:53 25-02-02 -0300, Juan M. Duran wrote: >Hi, I'm writting a small parser in Haskell and, when it is all done, I get >the following problem: Type Binding. >The thing is, I have 3 main functions: >1) Read the file, its type is: [Char] ->IO [Char] (see InputOutput.hs) >2) Parse a string (using words and readDec), its type is: Integral a => >[Char] -> [a] (see Parse.hs) >3) Parse a list of integer, its type is: [Float] -> [[Float]] >(Functions.hs) > >Now the problem is that I cannot run the first function, then use its >results as an input of the second function and, finally, its results as >the input of the third function. > >How can I fix this without modifing all my functions because they, >independly, works fine. > >Juan

5 6

Lazy Parsing
by Brandon Michael Moore 28 Feb '02

28 Feb '02

I'm wondering if there are any libraries out there for creating parsers that lazily build up their result. I know I could thread the remaining input through a parser by hand, but it seems like someone should have already done it. I'd like to be able to turn a stream of XML into a lazy tree of tags (probably Maybe tags, or Either errors tags), but I don't think HaXml and the like do that sort of thing. Branodn Moore

3 2

Re: Ground Up
by Ketil Z Malde 28 Feb '02

28 Feb '02

"Jerry, JiJie" <jerry(a)gime.com> writes: > While my goals are: > * Become a pragmatic haskell programmer in the shortest time > * At the minimal expense How far have you come? Are you comfortable with recursion? With the type system? IO? Monads in general? > * I still have no clue of most (ok, almost all) of what is being > discussed in this mailing list Me neither; don't let that worry you. I'd advise you to ignore threads about difficult issues -- a lot of stuff discussed here is rare borderline cases that are mostly of interest to implementors, and not you and me. :-) -kzm -- If I haven't seen further, it is by standing in the footprints of giants

2 1

Haskell in Space
by Christoph Lueth 28 Feb '02

28 Feb '02

Dear Haskell people, as the last exercise of a second-year undergraduate Haskell course I had the students write an asteroids-type game (older readers may remember this arcade classic from the last century) using the Hugs Graphics Library. I put some solutions up on a wee web-page, because I thought it might amuse some of you who teach or learn Haskell, and because frankly one of the students' solutions simply deserved some wider attention: http://www.informatik.uni-bremen.de/~cxl/haskell-in-space Enjoy, --Christoph.

2 1

Re: Lazy Parsing
by John Hughes 28 Feb '02

28 Feb '02

There's a combinator which Phil Wadler called "guarantee" which makes a parser lazy -- guarantee p succeeds at once, with a result which will be produced, when demanded, by p. Many parsing libraries include it under one name or another... John

1 0

Re: higher-kind deriving ... or not
by C T McBride 27 Feb '02

27 Feb '02

Hi On Thu, 28 Feb 2002, Tom Pledger wrote: > C T McBride writes: > | > data Fix f = Fix (f (Fix f)) > | > | There's no equivalent first-order definition. This is where > | higher-kind parameters actually buy us extra stuff, and it's also the > | point at which the first-order constraint for show becomes hopeless. > > Did you see the technique Mark Tullsen posted last year, for making > instances in the presence of a fixpoint? I've found it useful. > > http://haskell.cs.yale.edu/pipermail/haskell/2001-May/003942.html Thanks for the pointer. Yes, that looks like a kind of hard-coding of the lifting to higher kinds that I'm after. If I understand things correctly, it would seem that for every type class C t, indexed by types, one can manufacture the constructor class FC f which asserts that f preserves C-ness. For each C-method m :: blah[t] one gives the FC method fm :: C t => blah[f t] One can lift further, by defining classes for constructors with higher-kind parameters which take FC-ness (or whatever) to C-ness. Requiring FC f (a first-order constraint on a higher-kind thing) is a plausible fake of requiring (forall a. C a => C (f a)) (a higher-order constraint on types). If I read correctly, automating this construction, effectively yielding computation of classes from kinds, is part of Simon PJ and Ralf Hinze's `Deriving Type Classes' proposal. The functionality is clearly desirable. It does, however, come at the cost of introducing a third and still separate programming language as a component of Haskell---the language of programming over kinds. It's no good asking when this will stop, because it doesn't. It is worth asking when the different layers of this hierarchy will acquire a greater uniformity. Cheers Conor

1 0

RE: higher-kind deriving ... or not
by Simon Peyton-Jones 27 Feb '02

27 Feb '02

| > data Wonky f | > = Wonky | > | Manky (f (Wonky f)) | > deriving Show | | The trouble is that when I ask either hugs -98 or ghci | -fglasgow-exts to | | show (Wonky :: Wonky Copy) | | the poor compiler's brain explodes. I fixed this a few weeks ago. GHC (5.03) now says: Foo.hs:3: No instance for `Show (f (Wonky f))' When deriving the `Show' instance for type `Wonky' | I tried to guess the type of the show instance derived for | Wonky. Being a naive sort of chap, I thought it might be | | show :: (forall a. Show a => Show (f a)) => Wonky f -> String Not naive. That's exactly the right type. See Section 7 of "Derivable type classes". http://research.microsoft.com/~simonpj/Papers/derive.htm Havn't implemented this, yet, alas. | It's clear that with typing problems, inference becomes | unsustainable pretty soon after you leave the safe harbours | of the Hindley-Milner system. However, lots of lovely | programs have more interesting types: it would be very | frustrating if Haskell forbade these programs just because | their types were not inferrable---not least since, for these | jobs, we usually do think of the type first and the code | afterwards. Sensibly, Haskell allows us to write these types | down, so the machine's task is merely checking. This hybrid | approach preserves type inference for `old' code, whilst | promoting more adventurous programming by allowing us to say | what we mean when the machine is too dim to guess. I agree wholeheartedly with this; it's exactly the approach I'm trying to take with GHC. One obvious extension is to let the user specify the context for a derived instance decl, but still let the compiler generate the code. Havn't done this either! Simon

1 0