July 2001 - Haskell - Haskell.org

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

newbie conceptual question
by Cagdas Ozgenc 25 Jul '01

25 Jul '01

Greetings, I have been programming with imperative languages for 15 years. Now I started learning Haskell, and functional programming (and I am very determined to learn it well). It seems to me that I can still use functional programming paradigm with an imperative language. How can I benefit more from a functional programming language (i.e.Haskell)? In other words, is having built-in language constructs for functional programming the only reason for using a functional programming language(I can use polymorpim, and generic programming in imperative languages, as well). Thanks

2 2

RE: lexical description problem in language report?
by Simon Peyton-Jones 25 Jul '01

25 Jul '01

I agree with Thomas's suggestion: a) Change the definition of lexeme b) Move lexical discussion from 5.5.1 to 2.4 It also looks that Christian is correct in revising the details of (a). Thomas, do you agree? Would this resolve the various lexical issues? Thanks for your help. Simon | -----Original Message----- | From: Christian Sievers [mailto:sievers@ips.cs.tu-bs.de] | Sent: 24 July 2001 20:45 | To: haskell(a)haskell.org | Subject: Re: lexical description problem in language report? | | | Thomas Hallgren wrote: | | > program -> {lexeme | whitespace } | > lexeme -> varid | conid | varsym | consym | literal | special | | > reservedop | reservedid | > | > There is no reference to qualified names here. I thought | the purpose | > of | > these productions were to say that a Haskell program is | correct on the | > lexical level iff there is a derivation of it in the | lexical grammar, | > starting from the nonterminal "program". Since qualified | names are not | > part of this grammar, they are not part of the lexical | syntax, which | > contradicts the text in section 5.5.1. | > | > So, I repeat my improvment suggestions: include qvarid, | qconid, etc, | > in | > the production for lexeme. Move the explanation of the lexical | > properties of qualified names from section 5.5.1 to section 2.4. | | You could still parse a qualified name as three lexemes. | Of course you don't want this, as this would allow white | space between them. For the same reason, you want backquoted | functions and constructors to be only one lexeme. In order to | achieve this, just use qop instead of qvarsym and qconsym. | And we need opencom, as the report says {- is a lexeme. | | So I suggest: | | lexeme -> qvarid | qconid | qop | | literal | special | reservedop | reservedid | opencom | | | It's all not new. See: | http://www.dcs.gla.ac.uk/mail-| www/haskell/msg01596.html | | http://www.dcs.gla.ac.uk/mail-www/haskell/msg01730.html All the best Christian Sievers _______________________________________________ Haskell mailing list Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell

1 0

IFL 2001 call for registration
by thomas＠cslab.ericsson.se 25 Jul '01

25 Jul '01

IFL 2001 13th International Workshop on the IMPLEMENTATION OF FUNCTIONAL LANGUAGES Stockholm Sweden September 24 - 26, 2001 ============================================================= Registration deadline 15 August 2001 <<-- Submission deadline 1 September 2001 http://www.ericsson.com/cslab/ifl2001/ email: thomas(a)cslab.ericsson.se ============================================================= We have had problems with our web server. In case you registered and did not get a response, please register again. Due to this inconvenience registration will be possible until August 15! Please register before August 15, either via the web site or by returning the following information to me: name: affiliation=: address: country: phone: fax: email: web: talk: yes/no talktitle: attending Erlang User Conference (27/9): yes/no arrival: 24 Sept (or different date) departure: 27 Sept (or different date) diet: The registration fee is 1000 sek (about 100 euro) and should be paid on arrival. The hotel you should arrange yourself. See the web page for a list of hotels. A number of rooms is reserved in Globe Hotel. For the reduced price of 995 sek, to be obtained by giving the reference number MK 1636. http://www.globehotel.se/ phone: +46 8 686 6320 +46 8 686 6300 fax: +46 8 686 6301 mailto:bokning.globe@quality.choicehotels.se Best regards Thomas --- Thomas Arts Ericsson Computer Science Laboratory Box 1505 125 25 Stockholm Sweden thomas(a)cslab.ericsson.se

1 0