- Haskell - Haskell.org

RE: Haskell 98 Report possible errors, part one
by Simon Peyton-Jones 24 Jul '01

24 Jul '01

| 2.2. Identifiers can use small and large Unicode letters. | What about caseless scripts where letters are neither small | nor large? The description of module Char says: "For the | purposes of Haskell, any alphabetic character which is not | lower case is treated as upper case (Unicode actually has | three cases: upper, lower and title)". This suggests that the | only anomaly is that titlecase letters are considered | uppercase. But what is actually specified is that caseless | scripts can be used to write constructor names, but not to | variable names. I don't know how to solve this. I am woefully ignorant of Unicode, and I have no idea what to do about this one. I therefore propose to do nothing on the grounds that I might easily make matters worse. Simon

3 2

Re: Picky details about Unicode (was RE: Haskell 98 Report possible errors, part one)
by Marcin 'Qrczak' Kowalczyk 24 Jul '01

24 Jul '01

Mon, 23 Jul 2001 11:23:30 -0700, Mark P Jones <mpj(a)cse.ogi.edu> pisze: > I guess the intention here is that: > > symbol -> ascSymbol | uniSymbol_<special | _ | : | " | '> Right. > In fact, since all the characters in ascSymbol are either > punctuation or symbols in Unicode, the inclusion of ascSymbol > is redundant, and a better specification might be: > > symbol -> uniSymbol_<special | _ | : | " | '> It would still be nice to explicitly list ASCII symbols, so one doesn't need to look at Unicode specs to use ASCII-only source. There are two places when character predicates are used in Haskell: program source and module Char. I'm sure that we all agree that they should be consistent with each other. Some predicates in module Char are "wrong", i.e. I don't agree with their meaning. For example that isSpace is restricted to ISO-8859-1, and that caseless letters are considered uppercase. It's not clear what good definitions are, or even what set of predicates is useful, because there is no single official source with unambiguous and complete set of predicates. There are Unicode character categories, Unicode property lists, and implementations of C character predicates - all with different data. I guess Java specs have something to tell here too. I have an implemented proposal of improved Char predicates in QForeign <http://sf.net/projects/qforeign/>. Definitions are based on both Unicode character categories and PropList.txt from Unicode. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

hGetContents and laziness in file io
by Hal Daume 24 Jul '01

24 Jul '01

Hi! I have a few laziness/performace questions regarding file io in haskell (particularly hugs, right now). I'm writing a program that basically converts file formats. The files are parse trees for natural language. So I read in one of the parse trees in the original format and write it out again in my own format. I'm doing this is haskell because a) i like haskell, b) writing parsers in haskell is really easy. I'm currently using hGetContents to read the original file in, though I've also tried using readFile and the like. My basic problem is that the program takes a ridiculous amount of time to run and that it often runs out of heap. The file that I read in is basically just a sequence of parse trees, one after the other. I would *like* to basically read one in, parse it, convert it, write that to the output file. Read the next in, parse it, convert it, write it. Etc. The problem is that it seems that my program is trying to load the entire file into memory for just reading one tree. For instance, the file that I'm working with is ~20mb of trees. When I run my program on this, it is unable to reclaim space (unless i set the heap really high). However, if I simply extract the first, say, 4 trees and place these in a new file, the program runs to completion (albeit grindingly slowly). In my experience with other languages, this kind of slowness on file/io is usually due to trying to read on character at a time instead of a block...I can't figure out how to get this to behave properly though. I can post some of the code if people would like to read it, but basically it basically looks like this: convert inF outF = do inH <- openFile inF ReadMode ulf <- hGetContents inH outH <- openFile outF WriteMode parseAll outH ulf hClose inH hClose outH parseAll outH ulf = case parse s of Good (tree, rest) -> case convert tree of Good s' -> do hPutStrLn outFile s' Error err -> do putStrLn err Error err -> do return () where parse takes a string and parses it and convert takes the tree and converts it back to a string (in the other format)... PLEASE help! Thanks! -- Hal Daume III "Computer science is no more about computers | hdaume(a)isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

2 1

lexical description problem in language report?
by Memovich, Gary 24 Jul '01

24 Jul '01

I believe I've found a problem, or at least a confusion, in the Haskell 98 Language Report. The section on lexical structure seems to use the term "lexeme" in an inconsistent way. "lexeme" is one of the productions in the lexical grammar in section 2.2, but the term is also used in section 2.3 where it is claimed that the string "{-" is a lexeme. However the string "{-" cannot be produced by the given grammar production. Is section 2.3, and the discussion of the maximal-munch rule, using the term lexeme in a different way than the grammar production in section 2.2? If so, maybe a new term should be introduced such as "rawlexeme", with a production like: rawlexeme -> lexeme | opencom | closecom | dashes Then perhaps the maximal-munch rule could be described in terms of "rawlexeme". Any thoughts? -- Gary

2 1

Haskell 98 Report possible errors, part one
by Marcin 'Qrczak' Kowalczyk 23 Jul '01

23 Jul '01

0.4.1. "http:://haskell.org" - typo. Same in the Library Report. 2.2. "any UNIcode character" - spelling inconsistent with "Unicode" elsewhere. Same in appendix B. 2.2. Identifiers can use small and large Unicode letters. What about caseless scripts where letters are neither small nor large? The description of module Char says: "For the purposes of Haskell, any alphabetic character which is not lower case is treated as upper case (Unicode actually has three cases: upper, lower and title)". This suggests that the only anomaly is that titlecase letters are considered uppercase. But what is actually specified is that caseless scripts can be used to write constructor names, but not to variable names. I don't know how to solve this. 3. A precedence table says that case (rightwards) has higher precedence than operators and right associativity. If it's meaningful to talk about precedence of such syntactic constructs as case at all, it should probably be told to have a lower precedence, so "case x+1 of ..." is valid as "case (x+1) of ...". At least I don't see a difference between "case" (rightwards) and "if" (rightwards). I'm not sure if it makes sense to explain parsing of "case" in terms of precedence. 3.10. enumFrom* on Integer is specified as translated to and from Int. But I assume that [2^100..2^100+9]::[Integer] should work. 3.11. Translation of list comprehensions in a table inconsistently uses italic font for metavariables. 3.15.2 and elsewhere. Some translations to core use `undefined', others use `error "some message"'. Not a big deal, but perhaps could be consistent. 4. "cdecl -> gendecl | (funlhs | car) rhs" - typo, s/car/var/. 4.2.2. "A synonym and its definition are completely interchangeable." They are not in instance headers. But probably should be. 4.3.1. "A class declaration with no where part [...] The instance declaration must be given explicitly with no where part." Actually the where part may be present but empty, with the same meaning as no where part. Generally I'm not sure that having a layout rule which says that {} is inserted when the next indentation level is about to start and the new indent is smaller than the outer one is necessary; in all useful cases the keyword which triggered the layout could be omitted, and writing let x = case x of foo -> ... should be either an error or it should be allowed to have the next indent smaller than the previous one - it's not useful to let it mean let {x = case x of {}} foo -> ... and in case one really wants to have empty alts in case, he can write {} explicitly. 4.3.2. "The constructor is being instanced". Instantiated? 5.6.1. "an implicit `import qualified Prelude' is part of every module and names prefixed by `Prelude.' can always be used to refer to entities in the Prelude". So what happens in the following? module Test (null) where import Prelude hiding (null) null :: Int null = 0 module Test2 where import Test as Prelude import Prelude hiding (null) x :: Int x = Prelude.null ghc allows that, it dosen't seem to implement the qualified part of the implicit Prelude import. The report is contradictory: adding `import qualified Prelude' makes Prelude.null ambiguous, and thus names prefixed by `Prelude.' can't always be used to refer to entities in the Prelude. 5.8. "pop (Stk (x:s)) = Stk s" Consistency with the previous example suggests "pop (Stk (_:s)) = Stk s" 6.1.4. "There is no upper bound on the size of a tuple, but some Haskell implementations may restrict the size of tuples" - looks like a contradiction for me. Either there are no bounds or implementations may impose bounds. BTW, ghc should lift its limit for tuple instances. 6.3.2. max is defined in terms of ">=", min in terms of "<". ghc uses "<=" in both cases because "<=" is suggested to be the primary operation from which others are derived. Either should be fixed. I think the ghc version is better. 6.4.2. Laws for quot&rem and div&mod don't hold if the divisor is 0. 7. "semi-colon" - I think "semicolon" is the correct spelling (and used elsewhere). 7.1. "the IOError value associated with end-of-file is defined in a library". It is not: only isEOFError predicate is provided. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

2 1

RE: The Haskell Report
by Simon Peyton-Jones 23 Jul '01

23 Jul '01

You may be right, but the Report is neither confusing nor inconsistent on this point, I think. So I don't think it falls into the class of things that we can change for H98. You'll just have to add parens! Simon | -----Original Message----- | From: Ch. A. Herrmann [mailto:herrmann@infosun.fmi.uni-passau.de] | Sent: 23 July 2001 15:04 | To: haskell(a)haskell.org | Subject: The Haskell Report | | | Hi Haskellers, | | because I recognized that some people are discussing | the Haskell report, I'd like to point out a problem | concerning the operator precedences. | | At precedence level 9, there are the left associative | operator (!!) and the right associative operator (.), | but combining both directions doesn't make sense neither for me .. | | .. nor for ghci: | > gs !! i . f | > cannot mix `(!!)' [infixl 9] and `(.)' [infixr 9] in the | same infix expression | | It appears sensible for me that (!!) associates to the | left and I suppose that there is a strong requirement | for (.), which is associative anyway (f.g).h = f.(g.h), | to associate to the right, due to efficiency reasons. | However, what's the problem with introducing a precedence | level 10 and move (!!) upto it? | | Cheers | Christoph | | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell |

2 1

RE: Haskell 98 Report possible errors, part one
by Simon Peyton-Jones 23 Jul '01

23 Jul '01

| Unfortunately both the old and the new situation are not so | nice. Both don't allow a simple translation of Haskell into | the Haskell kernel, e.g. you cannot translate [1..] into | Prelude.enumFrom 1, because the latter may be ambiguous. | | The following remark at the beginning of Section 3 is misleading: | | Free variables and constructors used in these translations | refer to entities defined by the Prelude. To avoid clutter, | we use True instead of Prelude.True or map instead of | Prelude.map. (Prelude.True is a qualified name as described | in Section 5.3.) The report is vainly trying to say that, regardless of what is lexically in scope, the builtin syntax refers to Prelude entities. Perhaps I should reword the offending paragraph to say: Free variables and constructors used in these translations refer to entities defined by the Prelude, regardless of what variables or constructors are actually in scope. For example, "concatMap" used in the translation of list comprehensions (Section 3.11) means the "concatMap" defined by the Prelude, regardless of whether or not "concatMap" or "Prelude.concatMap" are in scope. Would that be better? Simon

2 1

Re: Haskell 98 Report possible errors, part one
by Marcin 'Qrczak' Kowalczyk 23 Jul '01

23 Jul '01

Mon, 23 Jul 2001 15:11:32 +0100, Olaf Chitil <olaf(a)cs.york.ac.uk> pisze: > Both don't allow a simple translation of Haskell into the Haskell > kernel, > e.g. you cannot translate [1..] into Prelude.enumFrom 1, because the > latter may be ambiguous. That's why I was proposing that importing another module as Prelude should be the way to change the meaning of builtin syntax in ghc, instead of -fno-implicit-prelude combined with importing some names to be available unqualified. It's not a change in the report, which doesn't support changing the meaning of builtin syntax and should only be clarified that entities refer to standard Prelude. But as an extension some builtin syntax in ghc might be defined as textual expansion to Prelude-qualified names, so they may come either from original Prelude or from a replacement. To complete that extension it should be legal to self-import: module MyPrelude where import MyPrelude as Prelude import Prelude as P so that 5 used in this very module expands to Prelude.fromIntegral 5, i.e. MyPrelude.fromIntegral 5. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

RE: Haskell 98 Report possible errors, part one
by Simon Peyton-Jones 23 Jul '01

23 Jul '01

Folks Marcin is right about this. It is inconsistent as it stands. I propose to delete the sentence "The Preldue module is always available as a qualified import..." in the first para of 5.6.1. The situation will then be: if you don't import Prelude explicitly, you implicitly get import Prelude if you do import Prelude explicitly, you get no implicit imports Nice and simple Simon | 5.6.1. "an implicit `import qualified Prelude' is part of | every module and names prefixed by `Prelude.' can always be | used to refer to entities in the Prelude". So what happens in | the following? | | module Test (null) where | import Prelude hiding (null) | null :: Int | null = 0 | | module Test2 where | import Test as Prelude | import Prelude hiding (null) | x :: Int | x = Prelude.null | | ghc allows that, it dosen't seem to implement the qualified | part of the implicit Prelude import. The report is | contradictory: adding `import qualified Prelude' makes | Prelude.null ambiguous, and thus names prefixed by `Prelude.' | can't always be used to refer to entities in the Prelude.

2 1

The Haskell Report
by Ch. A. Herrmann 23 Jul '01

23 Jul '01

Hi Haskellers, because I recognized that some people are discussing the Haskell report, I'd like to point out a problem concerning the operator precedences. At precedence level 9, there are the left associative operator (!!) and the right associative operator (.), but combining both directions doesn't make sense neither for me .. .. nor for ghci: > gs !! i . f > cannot mix `(!!)' [infixl 9] and `(.)' [infixr 9] in the same infix expression It appears sensible for me that (!!) associates to the left and I suppose that there is a strong requirement for (.), which is associative anyway (f.g).h = f.(g.h), to associate to the right, due to efficiency reasons. However, what's the problem with introducing a precedence level 10 and move (!!) upto it? Cheers Christoph

1 0