- Haskell - Haskell.org

Re: adventure game
by Ketil Malde 30 Jul '01

30 Jul '01

stanley goof <stanley_goof(a)yahoo.fr> writes: > I am planning to write a text-adventure game in > haskell. Right. > This is the type of game in which you can execute many > commands like 'take'(to take an object), 'goto' to > move from a room to another room, 'look'(to see the > objects in a room), 'open'(to open a drawer), ... I think perhaps Haskell is not ideal for this. Basically, you're describing lots of objects, on each of which you can peform certain actions depending on its type and state. If this doesn't ring a bell with you, I'll spell it out: Object Orientation. :-) You could of course do it in Haskell, and I'm toying with a simulation engine in it which isn't entirely different. I just don't think it's optimal, in particular if you're looking for a problem to hone your Haskell skills on. -kzm -- If I haven't seen further, it is by standing in the footprints of giants

1 0

foldl'
by Jon Fairbairn 28 Jul '01

28 Jul '01

Unless I'm mistaken, foldl' (the strict version of foldl) doesn't appear in (the export list of) the standard prelude or the list library. Is there a good reason for this? New users quite quickly find that they need it. Jón -- Jón Fairbairn Jon.Fairbairn(a)cl.cam.ac.uk 31 Chalmers Road jf(a)cl.cam.ac.uk Cambridge CB1 3SZ +44 1223 570179 (after 14:00 only, please!)

1 0

RE: computer language shootout
by brk＠jenkon.com 27 Jul '01

27 Jul '01

GHC ranks quite poorly currently. (I think there's an AWK implementation that's ahead of it, nevermind Ruby or Python). There are still a couple of benchmarks that haven't been implemented yet for Haskell, and a couple more that don't make sense for a non-OO language. I spent a little while working over the examples a month or two ago. I was able to shorten a number of them considerably, and even sped up a few. My difficulty was that I was writing for ghc-4.08 on Cygwin (Doug uses 5.02 on linux), so things that improved the speed on my windows box often reduced the speed on Doug's linux box! I'm still pretty new at Haskell, so it's probably worthwhile for some more expert folks to take a look at all the current implementations. I have to say (and this also relates to the newbie question thread) that I don't understand why GHC fares so poorly, and I guess I find it a little frustrating. It seems as though, by programming in Haskell with all its great semantic properties and opportunities for optimization, the compiler should be able to generate code that's enormously faster than the naive implementation, and easily competitive with C (or at least Ocaml!). Does anyone understand why this isn't the case now? Is it just that these things take time and they're being worked on, or do the techniques for this level of optimization not exist yet for lazy functional languages? Bryn > -----Original Message----- > From: Miles Egan [SMTP:miles@caddr.com] > Sent: Friday, July 27, 2001 7:55 AM > To: haskell(a)haskell.org > Subject: computer language shootout > > I apologize if this question has already been asked, but I couldn't find a > searchable version of the mail archive. > > Doug Bagley's computer language shootout, > http://www.bagley.org/~doug/shootout/, > a collection of mini-benchmarks in several languages, doesn't paint a very > flattering picture of GHC's performance. GHC is even ranked below Ruby > and > Python! Has anyone tried to optimize any of the GHC programs? > > Ocaml fares quite well in these tests and a glance at several of the Ocaml > programs suggests that most of them have been fairly aggressively > optimized. > These kinds of benchmarks are kind of silly, but also a good p.r. > opportunity. > > -- > miles > > "We in the past evade X, where X is something which we believe to be a > lion, through the act of running." - swiftrain(a)geocities.com > > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell

3 3

RE: computer language shootout
by brk＠jenkon.com 27 Jul '01

27 Jul '01

> -----Original Message----- > From: Miles Egan [SMTP:miles@caddr.com] > On Fri, Jul 27, 2001 at 10:11:20AM -0700, brk(a)jenkon.com wrote: > > I have to say (and this also relates to the newbie question thread) that > I > > don't understand why GHC fares so poorly, and I guess I find it a little > > frustrating. > > I think it's important to keep these benchmarks in perspective, though. > As Doug > Bagley himself says, these kinds of benchmarks are pretty hard to > interpret and > are subject to a lot of noise. Extrapolating performance on small > artificial > problems like this to real application performance is not at all > straightforward. That said, this is a small p.r. problem. > [Bryn Keller] While this is absolutely true, and well worth remembering, GHC's performance is in some cases reasonably competitive, but in others is many times slower than Ocaml. For instance: Times are C/Ocaml/GHC Sum a Column of Integers: 0.73 / 0.99 / 9.98 Array Access: 0.11/ 0.14 / 18.78 But there are also entries like: Ackermann's Function 0.09 / 0.04 / 0.06 Where Ocaml and GHC were both *faster* than C, and GHC was quite close to Ocaml. I'm just wondering why we can't get performance like (at least) Ocaml on all the tests, not just some. Bryn

2 1

computer language shootout
by Miles Egan 27 Jul '01

27 Jul '01

I apologize if this question has already been asked, but I couldn't find a searchable version of the mail archive. Doug Bagley's computer language shootout, http://www.bagley.org/~doug/shootout/, a collection of mini-benchmarks in several languages, doesn't paint a very flattering picture of GHC's performance. GHC is even ranked below Ruby and Python! Has anyone tried to optimize any of the GHC programs? Ocaml fares quite well in these tests and a glance at several of the Ocaml programs suggests that most of them have been fairly aggressively optimized. These kinds of benchmarks are kind of silly, but also a good p.r. opportunity. -- miles "We in the past evade X, where X is something which we believe to be a lion, through the act of running." - swiftrain(a)geocities.com

2 3

frp neophyte query (franTk specific)
by Amit Garg 27 Jul '01

27 Jul '01

Hi. Ive been trying to play with the functional reactive framework provided with franTk (i've also seen www.haskell.org/frp) In this context, i wanted to create an event stream to drive my programs ... i could not get 'toStream time' to work. My solution works essentially using this: wire <- newWire r <- addListener (event wire) (input wire) This creates a memory overflow eventually, and i can understand that. I also perceive from the earlier discussion that i should somehow be able to use fixIO to resolve this ... however a solution escapes me. :( Any ideas? Thank you. - Amit Garg. - Ph.D. student, UT-Austin.

1 1

newbie prelude question
by Cagdas Ozgenc 27 Jul '01

27 Jul '01

Hi, I was investigating the prelude the other day. I was bewildered with the highly complicated expressions, and interesting syntax. My question is : "are there any tweaks in the prelude?" I mean : are there any language constructs which have some sort of special treatment? Which ones are hard wired to the compiler? Am I free to use those special constructs defined in the prelude, in my own programs (other than the functions of course)? Thanks

1 0

Haskell IDE for Win32
by Rijk-Jan van Haaften 26 Jul '01

26 Jul '01

Hello haskell users, Today (July 26, 2001) I released a new version of the haskell support module for JCreator. You can get it from http://www.students.cs.uu.nl/people/rjchaaft/JCreator Rijk-Jan

1 0

Re: FW: Haskell 98 report problem re lexical structure.
by Marcin 'Qrczak' Kowalczyk 25 Jul '01

25 Jul '01

Wed, 25 Jul 2001 17:57:59 +0200 (MET DST), Christian Sievers <sievers(a)ips.cs.tu-bs.de> pisze: > The sequence of dashes must not be followed by another symbol, > for example --> or --| do not begin a comment, they are just > ordinary lexemes. Nor preceded. This is symmetrical, it's not dashes that start an operator but ones that are contained in it. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

FW: Haskell 98 report problem re lexical structure.
by Simon Peyton-Jones 25 Jul '01

25 Jul '01

I've looked again at what Gary says below, which relates somewhat to Christian/Thomas Hallgren's comments about lexical matters. Here's what I propose 1. I will use "lexeme" consistently to mean what the "lexeme" production means. 2. The place that "lexeme" is currently used inconsistently is in 2.3 (Comments) Here I propose to replace paras 2 and 3 thus: "An ordinary comment begins with a sequence of two or more consecutive dashes (e.g. --) and extends to the following newline. The sequence of dashes must not be the prefix of a legal lexeme. For example, @''">``-->'' <mailto:``@--> or ``--|' <mailto:``--|@''> do not begin a comment, because both of these are legal lexemes. A nested comment begins with ``{-'' <mailto:``{-@''> and ends with ``-}'' <mailto:``-}@''> . No legal lexeme starts with ``{-'' <mailto:``{-@''> ; hence, for exmaple, ``{---'' <mailto:``{---@''> starts a nested comment despite the trailing dashes." 3. "--" and "---" are not legal a legal "varsym", so the production for "varsym" should exclude "dashes" as well as "reservedop". 4. I believe that the production for "ANY" should include "return", "linefeed" and "uniWhite". 5. [Re Christian S's proposal, which I sent earlier, remove "opencom" from "lexeme"] I think that does it. Pls confirm or deny. Simon -----Original Message----- From: Memovich, Gary [mailto:GARY.MEMOVICH@kla-tencor.com] Sent: 19 July 2001 18:53 To: Simon Peyton-Jones Subject: Haskell 98 report problem re lexical structure. Hello, I've been studying the Haskell 98 report and think there are a few problems in the section on lexical structure. First, the difference between "lexeme" considered as a production in the grammar and "lexeme" used in the more general sense is very confusing. The fact that "lexeme" as a grammar production is only distinguished by being in italic font is easy to overlook. Also, no definition of "lexeme" in the general sense, is given. I gather that strings matching the productions "dashes", "opencom", and "closecom" are all considered lexemes, but that strings matching "comment" and "ncomment" are not. But this is not explicitly stated anywhere. Also the string "---", for example, matches both the productions "varsym" and "dashes", so the fact that it should be considered the beginning of a comment is not decided by the maximal-munch rule alone. Perhaps the definition of "varsym" should explicitly rule out strings matching "dashes" in the same way it rules out strings matching "reservedop". As a second issue, it is stated at the end of section 2.2 that characters not in the category "ANY" are not valid in Haskell programs. But the productions "return", "linefeed", and "uniWhite", which are not included in the production "ANY", are explicitly included in the production "whitechar" which implies that they can be used in programs, at least in a limited way. I recently posted a message to the Haskell mailing list that was related to some of these same issues, but I now consider that message obsolete. Thanks for your time and attention, -- Gary

2 1