- Haskell - Haskell.org

ANNOUNCE: Happy 1.10 released
by Simon Marlow 13 May '01

13 May '01

ANNOUNCING Happy 1.10 - The LALR(1) Parser Generator for Haskell ----------------------------------------------------------------- I'm pleased to announce version 1.10 of Happy, the parser generator system for Haskell. Changes in this version, relative to version 1.10 (the previous full release): * bugfixes, and minor performance improvements, * most of the examples work again. Happy is available in source form, which can be compiled with GHC version 4.xx (4.08 or 5.00 recommended), and we also provide binaries for some architectures. The Happy homepage with links to the various distributions lives at: http://www.haskell.org/happy/ Please send any bug reports and comments to simonmar(a)microsoft.com.

4 4

Re: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released)
by cwitty＠newtonlabs.com 13 May '01

13 May '01

"Manuel M. T. Chakravarty" <chak(a)cse.unsw.edu.au> writes: > I don't think, the point is the test for non-ambiguity. At > least, Doitse's and my self-optimising parser combinator > library will detect that a grammar is ambigious when you > parse a sentence involving the ambiguous productions. So, > you can check that by parsing a file involving all grammar > constructs of the language. Sorry, doesn't work. Where do you get this "file involving all grammar constructs of the language"? If such an approach worked, you could use it to determine whether an arbitrary context-free grammar was ambiguous; but this problem is undecidable. Carl Witty

3 2

RE: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released)
by Simon Marlow 11 May '01

11 May '01

S. Alexander Jacobson writes: > I am not a parsing expert, but given the recent discussion on > macros, I > have to ask: why use happy rather than monadic parsing? > Monadic parsing > allows you to avoid a whole additional language/compilation > step and work > in Hugs (where you don't have a makefile). What does Happy > buy you here? It buys you (a) speed, (b) confidence that your grammar is non-ambiguous, and (c) familiar BNF notation. On the down side, as you point out, you lose Haskell's abstraction facilities. I'd be willing to sacrifice (c) in order to write parsers in Haskell, but I don't think there's a combinator library that matches Happy in terms of speed (disclaimer: I haven't exhaustively tested them all, but given the tricks Happy does I'd be surprised). AFAIK none of the combinator libraries gives you (b). Cheers, Simon

4 3

RE: sharing datatypes : best practice ?
by Taesch, Luc 11 May '01

11 May '01

do u isolate just the datatype, or a few related with, in a very small file (header like, i would say) or some basic accessor function with it ? isnt it leading to massiv quantities of small files ? > -----Original Message----- > From: Jan Kort [mailto:kort@science.uva.nl] > Sent: Donnerstag, 10. Mai 2001 16:36 > To: Taesch, Luc > Cc: 'haskell(a)haskell.org' > Subject: Re: sharing datatypes : best practice ? > > > "Taesch, Luc" wrote: > > > > i ve developped a datatype in a module P, and another > module will use it, and most probably a few others, and its > quite central to the apps Im building. > > > > what is the best organisation ? > > > > -import module P everywhere > > - isolate this datatype in a module, which would be > imported everywhere ?(very "include like") > > - merging the module around this datatype ? > > > > this last option is not a good option here as : > > - this would be too big > > - P is generated by Happy. > > Hi Luc, > Isolating the datatype in a module is what I always do. > Only "Main.hs" calls the happy parser and just about > every module uses the datatype, so it makes sense to > separate them. > > Jan > This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. CREDIT SUISSE GROUP and each of its subsidiaries each reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity. Unless otherwise stated, any pricing information given in this message is indicative only, is subject to change and does not constitute an offer to deal at any price quoted. Any reference to the terms of executed transactions should be treated as preliminary only and subject to our formal written confirmation.

1 0

haskell wiki wiped ?
by Taesch, Luc 11 May '01

11 May '01

i tried to acces the hasakell wiki ? it s just all blank. has it been purged ? i remember having seen some idioms ... This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. CREDIT SUISSE GROUP and each of its subsidiaries each reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity. Unless otherwise stated, any pricing information given in this message is indicative only, is subject to change and does not constitute an offer to deal at any price quoted. Any reference to the terms of executed transactions should be treated as preliminary only and subject to our formal written confirmation.

1 0

Fundeps and class contexts
by Marcin 'Qrczak' Kowalczyk 10 May '01

10 May '01

Would allowing this make sense? class C a b | a -> b class C a b => S a I want to simulate a particular "class synonym" (with four superclasses instead of one C here) where the type 'b' is uninteresting for its users. Currently I have to write class C a b | a -> b class C a b => S a b | a -> b and use f :: S a b => T(a) instead of f :: S a => T(a) even though T(a) usually doesn't contain b. If it does, I would write f :: (S a, C a b) => T(a) -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

Re: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released)
by cwitty＠newtonlabs.com 10 May '01

10 May '01

"S. Alexander Jacobson" <alex(a)shop.com> writes: > I am not a parsing expert, but given the recent discussion on macros, I > have to ask: why use happy rather than monadic parsing? Monadic parsing > allows you to avoid a whole additional language/compilation step and work > in Hugs (where you don't have a makefile). What does Happy buy you here? I've used Happy instead of parser combinators because I wanted the additional global error-checking. I believe that the standard implementations of parser combinators will allow you to specify an ambiguous grammar, and return one of the multiple possible parses, without warning. Carl Witty

1 0

sharing datatypes : best practice ?
by Taesch, Luc 10 May '01

10 May '01

i ve developped a datatype in a module P, and another module will use it, and most probably a few others, and its quite central to the apps Im building. what is the best organisation ? -import module P everywhere - isolate this datatype in a module, which would be imported everywhere ?(very "include like") - merging the module around this datatype ? this last option is not a good option here as : - this would be too big - P is generated by Happy. this look very much like a OO/non OO debate, which I dont want to spawn again. I can suppose its a FAQ like question. any good pointer ? whats the best practice around ? thanks Luc This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. CREDIT SUISSE GROUP and each of its subsidiaries each reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity. Unless otherwise stated, any pricing information given in this message is indicative only, is subject to change and does not constitute an offer to deal at any price quoted. Any reference to the terms of executed transactions should be treated as preliminary only and subject to our formal written confirmation.

2 1

The definition of lhsfun in the report
by Mads Lindstrøm 10 May '01

10 May '01

I'am confused about the "funlhs" production, in "Report on the programming Language Haskell 98" of the 1st February 1999. In the report one of the "funlhs"-productions is (see page 127): funlhs -> var apat {apat} That is a <var> followed by one to many <apat>. But you can have functions like this: fun :: Int fun = 17 That is without any patterns to match, so why is the rule not ? funlhs -> var {apat} That is a <var> followed by zero to many <apat>. I will be very happy for an answer to my question. _______________________________________________________ Send a cool gift with your E-Card http://www.bluemountain.com/giftcenter/

2 1

Class RealFrac: round
by Rijk-Jan van Haaften 09 May '01

09 May '01

Hello, While I were writing a RealFrac implementation for BigDouble's (for high-precision computations) I found a strange implementation of round in the standard prelude (from the haskell definition): round x = let (n,r) = properFraction x m = if r < 0 then n - 1 else n + 1 in case signum (abs r - 0.5) of -1 -> n 0 -> if even n then n else m 1 -> m The strange case is if signum (abs r - 0.5) is 0: such numbers are round to the nearest EVEN integer. In mathematics, computer science (the studies I'm doing) and physics, as far as I know, it is usual to round such numbers up, rather than to the nearest integer. For example: Number Hugs Math 0.5 0 1 1.5 2 2 -3.5 -4 -4 6.5 6 7 Why did the Haskell designers choose this behaviour? Thanks in advance, Rijk-Jan van Haaften

3 2