- Haskell - Haskell.org

Behavior of fromInteger on out-of-range arguments
by David Feuer 26 Feb '02

26 Feb '02

What about having Int be considered a restricted integer that notices overflow, and create another type (bit bunch?) that does not notice overflow, and require explicit conversion to go from one to the other? This would seem to be the best of both worlds. The "bit bunch" type could also provide useful info about its size. It could even be possible to have a "machine-specific bit-bunch" of the same size as an Int or bit bunch, but with machine-specified overflow behavior that the programmer can discover (whether this should be at compile-time or run-time I couldn't say). Question: Is there any standard way in Haskell of determining the maximal and minimal Int values? If not, there should. David Feuer

3 2

RE: Behavior of fromInteger on out-of-range arguments
by Simon Peyton-Jones 26 Feb '02

26 Feb '02

| 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. Actually, it'd be an easy, non-destablising change to make to the Report to specify the behaviour of the Int instance of fromInteger on numbers larger than will fit in an Int. If a consensus emerges I'm quite happy to enshrine it in H98. Simon

3 2

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