February 2002 - Haskell

RE: H98 Report: expression syntax glitch
by Simon Peyton-Jones 26 Feb '02

26 Feb '02

| Consider the following Haskell 98 expressions: | | (let x = 10 in x `div`) | (let x = 10 in x `div` 3) | | To parse the first, a bottom-up parser should reduce the | let-expression before the operator, while to parse the second | it should shift. But it needs 4 tokens of lookahead to decide | which to do. That seems unreasonable, and is well beyond the | LALR(1) parsers used by Hugs and GHC. Replacing `div` by + | needs 2 tokens of lookahead, which is still too much. I think | the first should be made illegal, but can't think of a clean | rule. (There are similar expressions using lambda and if.) Thanks to Ross for identifying this glitch, and for others who followed up. The real problem seems to be the notion of "as far to the right as possible" because that implies "as far to the right as can be done without a parse error", and that in turn depends on associativity etc. Simon and I came up with the following alternative formulation for the meta-rule that disambiguates let, lambda, and if: Replace "The ambiguity is resolved by the meta rule that each of these constructs extends as far to the right as possible" by "The ambiguity is resolved by the meta rule that each of these constructs extends to the nearest occurrence of the following punctuation symbols that does not form part of a nested expression: ) ] } | ; , .. where of then else For example: (\x -> x + (x*x) ) Lambda extends to the second ')' because the first ')' forms part of a nested expression " This formulation means that (let x = 10 in x `div`) would be a syntax error, because the `div` cannot terminate the rightward reach of the 'let'. Similarly, let x = 10 in x == x == True is a syntax error because the let cannot be terminated by the second '=='. Can anyone think of a way to improve on this? Simon

2 1

Behavior of fromInteger on out-of-range arguments
by Jan-Willem Maessen 26 Feb '02

26 Feb '02

I've recently run up against the following rather annoying inconsistency between haskell implementations: HUGS: Nat> fromInteger 4294967264 :: Int Program error: {primIntegerToInt 4294967264} GHCI: Nat> fromInteger 4294967264 :: Int -32 I don't have nhc installed at the moment, so I can't tell you offhand which side of the debate it falls on. There are interesting arguments for both views, depending on whether you think of Int as being "Signed integers modulo 2^k" or "fast but impoverished integers". The difference only becomes a real problem when we add Int and Word: multiple sizes of signed and unsigned ints. How do we convert between them? In particular, how do we do a simple bitwise conversion between, say, Int32 and Word32? GHC takes the position that "fromIntegral is the only tool you will ever need". Hugs provides a special conversion routine for every pair of types. I'm trying to write code which works in both systems (and hopefully can be used in nhc as well). As a result, I'd love to see a consistent story here. It'd be lovely if the Haskell report took a stand on the issue, but I suspect that may be too much to hope for. Absent a cue in the report, it seems the FFI specification of the Int and Word should specify how to interconvert between the various types. I'm actually rather fond of the "integers modulo 2^k" view of Int and its ken. I think it does a grave disservice to beginning programmers to tell them that Int is simply a fast, impoverished Integer; I expect expert programmers to understand range limits and overflow. It also means that there are a few nice algebraic identites involving "fromInteger": (fromInteger (a + b) :: Int) == (fromInteger a + fromInteger b :: Int) (fromInteger (a - b) :: Int) == (fromInteger a - fromInteger b :: Int) etc... Frankly, though, I see compelling aesthetic arguments for either behavior. I'd rather implementations agreed on the behavior of fromInteger, than see my "favorite" behavior supported. -Jan-Willem Maessen PS - I should note that I don't use the FFI, nor do I have any immediate intention of doing so. I'm using Word types because comparison of Words interacts nicely with bitwise operations.

1 0

RE: H98 Report: expression syntax glitch
by Simon Marlow 26 Feb '02

26 Feb '02

> On Mon, Feb 25, 2002 at 05:07:35PM -0000, Simon Marlow wrote: > > On the other hand, one way to fix this problem *is* to specify the > > relative precedence of 'let' & co. as compared to infix operators > > (namely that 'let' should have a lower precedence). That would be a > > reasonable fix for the H98 report, IMO. > > Except that it would break programs containing expressions like > > 1 + let x = 2 in e > > or (if you do the same for lambda) > > f $ \x -> e > > The old table had let (and if and lambda) in two places, which is > more less what GHC/Hugs do, but not a mere clarification. Yes *sigh* I hadn't noticed that the table had one precedence for "leftwards" and a different one for "rightwards". Nevertheless, the report needs clarifying on this point. Cheers, Simon

1 0

Re: Help
by Juan M. Duran 25 Feb '02

25 Feb '02

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

2 1

RE: H98 Report: expression syntax glitch
by Simon Marlow 25 Feb '02

25 Feb '02

> In the table of precedence in the original Report (now deleted in > the revised Report), it makes it clear that a rightward-extending > let, if, or lambda has a lower precedence than an infix operator, > so for instance the parse > > h = (let op x y = y in (3 `op`)) > > is correct and > > h = ((let op x y = y in 3) `op`) > > is not. Actually the table claims that 'let' has a higher precedence than infix operators, so your second example above would be the correct parse according to the table. This may be one of the reasons it was removed, I can't remember now. Also, the table wasn't supposed to contain any extra information that isn't already in the grammar (Section 3: "As an aid to undertanding the grammar, Table 1 shows the relative precedences..."), so if the table is required to understand a particular parse, it would indicate a deficiency or ambiguity in the grammar. On the other hand, one way to fix this problem *is* to specify the relative precedence of 'let' & co. as compared to infix operators (namely that 'let' should have a lower precedence). That would be a reasonable fix for the H98 report, IMO. Cheers, Simon

2 1

H98 Report: expression syntax glitch
by S.M.Kahrs 25 Feb '02

25 Feb '02

Ross's example reminds me of a problem I once reported about the SML syntax. In Haskell, it is ambiguated, vaguely: False && if undefined then undefined else undefined || True ...is what? Apparently, it is False, on the grounds of the 'extends as far right as possible' meta-rule for if/lambda/let. That rule favours bottom-up over (clever) top-down parsing, because a top-down parser could mistakenly believe that '||' is the outermost operator - giving us a True expression.

1 0

Verba Volant
by subscribe_verba＠logos.net 25 Feb '02

25 Feb '02

The following email address, "haskell(a)haskell.org" has been removed from the Verba Volant Newsletter list. If you did not cancel your email address or you wish to continue receiving Verba Volant, please send an e-mail to subscribe_verba(a)logos.net Thank you and best regards, Verba Volant

1 0

Is there a more-robust FiniteMap?
by Tom Moertel 25 Feb '02

25 Feb '02

Using FiniteMap, I often run into robustness problems. For example, consider the following program, which illustrates a common problem: module Main (main) where import FiniteMap main = print . last . fmToList . listToFM $ [(i,()) | i <- [0..100000]] When compiled with ghc-5.02.2-1 on Red Hat Linux 6.2 $ ghc --make -package data -O2 -o test5 test5 and executed, the program quickly dies: $ ./test5 Stack space overflow: current size 1048576 bytes. Use `+RTS -Ksize' to increase it. Similarly, under hugs: $ hugs -h10M __ __ __ __ ____ ___ _________________________________________ || || || || || || ||__ Hugs 98: Based on the Haskell 98 standard ||___|| ||__|| ||__|| __|| Copyright (c) 1994-2001 ||---|| ___|| World Wide Web: http://haskell.org/hugs || || Report bugs to: hugs-bugs(a)haskell.org || || Version: December 2001 _________________________________________ Haskell 98 mode: Restart with command line option -98 to enable extensions Reading file "/usr/share/hugs/lib/Prelude.hs": Hugs session for: /usr/share/hugs/lib/Prelude.hs Type :? for help Prelude> :load test5.hs Reading file "test5.hs": Reading file "/usr/share/hugs/lib/exts/FiniteMap.lhs": Reading file "/usr/share/hugs/lib/Maybe.hs": Reading file "/usr/share/hugs/lib/exts/FiniteMap.lhs": Reading file "test5.hs": Hugs session for: /usr/share/hugs/lib/Prelude.hs /usr/share/hugs/lib/Maybe.hs /usr/share/hugs/lib/exts/FiniteMap.lhs test5.hs Main> main Segmentation fault (core dumped) This leaves a 90-MB core file, not exactly the output I was expecting! ;-) Looking through the FiniteMap sources, one sees that foldl-like behavior is at the heart of both listToFM and fmToList, not to mention many other FiniteMap favorites. Doesn't this make these functions -- and perhaps FiniteMap itself -- stack hungry and generally unreliable for large sets of data? Please help me understand the underlying issues better. Maybe FiniteMap is fine as it is, and I'm just doing something wrong. Should I be providing better strictness hints to the compiler? Am I using FiniteMap in a manner for which it wasn't intended? Should I write application-specific versions of FiniteMap for particular uses? Or is there an industrial-strength FiniteMap that I can rely on for all purposes? Thanks in advance for any hints, tips, and wisdom that you can share. Cheers, Tom

2 1

FW: Survival of generic-classes in ghc
by Simon Peyton-Jones 25 Feb '02

25 Feb '02

I had meant to send this message to the Haskell list, because I think there may be some readers who have good ideas about it. Simon -----Original Message----- From: Simon Peyton-Jones [mailto:simonpj@microsoft.com] Sent: 20 February 2002 21:16 To: Patrik Jansson; Haskell Cafe List Cc: Ralf Hinze; Johan Jeuring Subject: RE: Survival of generic-classes in ghc | and I know from testing earlier versions that the | generic-classes support was pretty buggy. Is there any hope | of a revival? Does it already work in CVS? I suspect it will | rot away if nobody works on it. | | Any comments from the implementors - does the idea "fit well" | with ghc? Is it a lot of work to make it more stable? No, it should not be a lot of work to revive, and I will do it. Keep bugging me until I do. One thing that is slowing me down is a design uncertainty: how to deal cleanly with constructors. To write read, show, etc, one needs access to the constructor name, fixity etc. We dance around that a little in the paper. I'm thinking of this design: -- An example data type data List a = Nil | Cons a (List a) -- The "ring" type derived from it -- Note the Con wrapped around the constructors data ListO a = Con NilT 1 :+: Con ConsT (a :*: List a) -- Con is part of the Generics library, like 1, :*:, :+: newtype Con c a = Con a class ConCls c where name :: c -> String arity :: c -> Arity ..etc.. data NilT -- Phantom types data ConsT -- one per constructor instance ConCls NilT where name _ = "Nil" ...etc... instance ConCls ConsT wher name _ = "Cons" ...etc... Now you can write class Show a where show :: a -> String show {| Con c t |} (Con x) = (name (undefined::c)) ++ show x ...etc.. Note the "undefined::c"; it is really just a type argument to "name", so that we get the string for the right constructor. It's a bit clunky, though. Another possiblity would be to make the ConCls class look like this class ConCls c where name :: String arity :: Int ...etc... Now we'd have to give an explicit type argument at the call site: show {| Constr c t |} (Con x) = (name {| c |}) ++ show x I quite like the thought of being able to supply explicit type arguments.... but I don't konw how to speak about the order of type parameters. What order does map takes its two type parameters in? Another question is whether we need an indication that we have reached a field of the constructor. Should we have: data ListO a = Con NilT (Field 1) :+: Con ConsT (Field a :*: (Field List a)) newtype Field a = Field a Without this, it's hard to write a generic function to count the number of fields of the data type. But in general, one might want to know when making the transition from "this" type to the argument types of the constructors. I think that the main reason I'm not making much progress is that I don't know what design choices to make. I'd be glad to discuss it with interested parties. Simon

1 0

ANNOUNCE: HUnit 1.0
by Dean Herington 22 Feb '02

22 Feb '02

HUnit is a unit testing framework for Haskell, similar to JUnit for Java. I have made HUnit 1.0 available at <http://hunit.sourceforge.net>. >From the User's Guide: A test-centered methodology for software development is most effective when tests are easy to create, change, and execute. The JUnit tool pioneered support for test-first development in Java. HUnit is an adaptation of JUnit to Haskell, a general-purpose, purely functional programming language. With HUnit, as with JUnit, you can easily create tests, name them, group them into suites, and execute them, with the framework checking the results automatically. Test specification in HUnit is even more concise and flexible than in JUnit, thanks to the nature of the Haskell language. HUnit currently includes only a text-based test controller, but the framework is designed for easy extension. (Would anyone care to write a graphical test controller for HUnit?) Dean Herington

1 0