- Haskell-Cafe - Haskell.org

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

RE: Ground Up
by Konst Sushenko 28 Feb '02

28 Feb '02

a word from a beginner (with a CS background): Alternatively, just do not use compiler specific features in your programs and this will make your programs work with different compilers. I went away from Lisp because there are no types. someone said once that Lisp is a sort of intermediate language that many people happen to like to program in. an assembly language of sorts. I went away from ML because once I got a taste of laziness, having my parameters evaluated before my function is called started to upset me ;-), and also I do not like that I have to use tuples in ML's datatypes. At least I did not find a way to not use them... But then of course one starts seeing all these problems with expressions taking too much heap space when writing programs of considerable size... But then using a purely functional language will teach you to forget trying to change a tuple or anything else in place (although I saw libraries in GHC that can change arrays, etc, in-place but I never used them), which is helpful I believe because it gives a different perspective on writing code. konst > -----Original Message----- > From: Max Kirillov [mailto:max630@mail.ru] > Sent: Thursday, February 28, 2002 1:10 PM > To: haskell-cafe(a)haskell.org > Subject: Re: Ground Up > > > Hi! > > I'm far not an expert in Haskell, but I'll venture to say > "I'm in". I'm not an CS student and I have never been (I > learned Solid State Physics). I became there in about 6 > months without paying a cent. Well, I paid for dialup. I > also spent a lot of time. My wife should hate Haskell. > > I would recommend you not to be confined by Haskell. Take a > look at Lisp, ML. First, it helps to get into concepts > rather than into details of syntax parsing of high-order > polymorphism. I began learning FP with Erlang, and I think > it helped me. > > Further, Haskell, though _very_ nice, is probably not "the > best choice" for a "pragmatic programming". It is too alive. > Different compilers are not 100% compatible each to other, > and even different versions of the same compilers may be > incompatible. You should be ready either to stick yourself > and your co-wokers to a certain version of the compiler or > to spend some significal time to keep you programs working > with any compiler. > > Maybe you will find that it's better to use Ocaml or > Scheme. Thay have own neats, and seem to be more stable. > > Max. > > On Thu, Feb 28, 2002 at 09:41:10PM +0800, Jerry, JiJie wrote: > > 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 > > _______________________________________________ > > 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

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

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

27 Feb '02

Hi I'm rather fond of fixpoint constructions like this one: > newtype Copy a = Copy a deriving Show > data Wonky f > = Wonky > | Manky (f (Wonky f)) > deriving Show (Clearly this is an ill-motivated example, but the real example which caused this problem is available on request...) 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 take it this is a known problem with instance inference, deriving, etc. Of course, it's easy to write my own show for Wonky Copy, but that's a tad annoying. 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 but that's a syntax error. A little more tinkering, and it looks like it might be show :: Show (f (Wonky f)) => Wonky f -> String Is this really the type of show? If so, no wonder there's a problem. I don't want to start an argument about how to solve this problem. I do want to suggest that, for the time being, it would be better to reject `deriving Show' for type constructors like Wonky (ie those with higher-kind parameters) than to generate instances which break the compiler. Or am I just being a spoilsport? Conor

3 4

java program
by Stewart Litt 26 Feb '02

26 Feb '02

dear sir/madam iam contacting you regarding a java problem which i have come across. My teacher at manchester met has set a problem for us to solve but thinking his teaching is excellent and everyone understands him wen no one does I would appreciate you helping me in this problem as it would save us from embarrassment. THE PROBLEM: Consider a simplified plan of the liverpool bus system. The system consists of a network of bus stops(at most 20) and bus lines (at most 5). Each bus stop has a unique name and each busline has a unique number. Each bus stop is connected to other bus stops by at most 3 different bus lines. Each of these bus lines connects a bus stop to exactly one other bus stop and for each bus stop and each connecting bus line it is known how many minutes the bus needs to get to the next bus stop. The objectives are to design and implement in java: 1. A representation of the bus system using suitable data structures. 2. A mechanism to go from one bus stop to a conected bus stop via a particular bus line. 3. A mechanism for searching for a connection between two given bus stops. A command line text based interface should be provided that will allow the user to issue a series of the following five commands: start: Allows to enter the current bus stop by name and resets the total journey time to zero. list: The system will show the total journey time so far, and all information on the current bus stop, that is, its name and the numbers of all outgoing bus lines. go: The system asks for the number of a busline. If the number is that of an outgoing busline, then the system finds out the busstop connected to the current bus stop and makes it the new current bus stop. If the number is not that of an outgoing bus line, then the system will indicate this by a message , but make no other changes. search: The system asks for the name of a bus stop. The system will then indicate whether there is a way to get to this bus stop from the current bus stop, but makes no other changes. exit: Stops and exits the system. Description of the liverpool bus stop below. THE LIVERPOOL BUS SYSTEM Bus Stop Outgoing bus line Connected bus stop Time in mins Bootle strand 22 South road 11 Pier head 10 Shiel road 14 22 Bootle strand 7 79 Edge hill 11 Edge hill 79 Picton clock 10 Green lane 10 Page moss 13 22 Bootle strand 18 Page moss 10 Prescot 8 Picton clock 79 Netherly 21 Shiel road 10 Green lane 5 South road 22 Green lane 9 _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx

1 0