- Haskell - Haskell.org

Minor inconsistency in the report wrt to qualified names
by Wolfgang Lux 24 Jul '01

24 Jul '01

In section 5.5.1 the report states that a top-level declaration brings into scope qualified and unqualified names. Thus, the following declaration is legal: module Foo where ones = 1 : Foo.ones However, in section 2.4 the report says "External names may optionally be qualified in certain circumstances by prepending them with a module identifier." And also in section 3.2 the report says "Qualified names may only be used to reference and imported variable or constructor", from which the above program would not be legal (because Foo.ones is not an imported constructor or variable). In order to make the report consistent, I would suggest to change the section 3.2 to say: "Qualified names may be used to reference variables or constructors which are imported from other modules or defined at the top level." In section 2.4, the word "External" should be dropped from the sentence. Wolfgang -- Wolfgang Lux Phone: +49-251-83-38263 Institut fuer Wirtschaftinformatik FAX: +49-251-83-38259 Universitaet Muenster Email: wlux(a)uni-muenster.de

1 0

Re: beginner's questions - fix f
by Marcin 'Qrczak' Kowalczyk 24 Jul '01

24 Jul '01

24 Jul 2001 12:04:33 -0000, Lars Henrik Mathiesen <thorinn(a)diku.dk> pisze: > Now, anything that's defined as "x = f x" is called a fixpoint of f. > It's possible to prove that there's only one (when f is a Haskell > function, at least) so we can talk of 'the' fixpoint. Not necessarily only one, e.g. any value is a fixpoint of identity function. But there is one *least* fixpoint wrt. definedness, and it can be effectively found. If the function is strict, the least fixpoint is not very interesting because it's bottom, a value representing nontermination or error. If the function is not strict, bottom is not its fixpoint, so the fixpoint obtained by "x = f x" or "fix f" is more interesting. BTW, a better definition than fix f = f (fix f) is fix f = let x = f x in x because it increases sharing, avoiding recomputation. > fix f = f (fix f) > > This looks like a recursive definition again, but if you want a system > without explicit recursion you have to disallow this as a function. In > such a system, fix is a builtin operator, You can define fix without recursion in a typeless lambda calculus: fix f = (\x -> f (x x)) (\x -> f (x x)) and this can even be stretched to fit Haskell's type system by smart use of algebraic types. > Note that operationally, this Haskell version of the fixpoint operator > is only sort-of equivalent to a Haskell recursive definition (which is > defined in terms of a 'real' fixpoint). That's even clearer with data > structures; compare > > zeroes = 0 :: zeroes > > and > > zer_step l = 0 :: l > zeroes2 = fix zer_step > > zeroes is a circular list with one element, while zeroes2 is an > infinite list with all zero elements. This is the difference between two definitions of fix above. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

3 2

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