FW: Haskell 98 report problem re lexical structure.
I've looked again at what Gary says below, which relates somewhat to Christian/Thomas Hallgren's comments about lexical matters. Here's what I propose 1. I will use "lexeme" consistently to mean what the "lexeme" production means. 2. The place that "lexeme" is currently used inconsistently is in 2.3 (Comments) Here I propose to replace paras 2 and 3 thus: "An ordinary comment begins with a sequence of two or more consecutive dashes (e.g. --) and extends to the following newline. The sequence of dashes must not be the prefix of a legal lexeme. For example, @''">``-->'' <mailto:``@--> or ``--|' <mailto:``--|@''> do not begin a comment, because both of these are legal lexemes. A nested comment begins with ``{-'' <mailto:``{-@''> and ends with ``-}'' <mailto:``-}@''> . No legal lexeme starts with ``{-'' <mailto:``{-@''> ; hence, for exmaple, ``{---'' <mailto:``{---@''> starts a nested comment despite the trailing dashes." 3. "--" and "---" are not legal a legal "varsym", so the production for "varsym" should exclude "dashes" as well as "reservedop". 4. I believe that the production for "ANY" should include "return", "linefeed" and "uniWhite". 5. [Re Christian S's proposal, which I sent earlier, remove "opencom" from "lexeme"] I think that does it. Pls confirm or deny. Simon -----Original Message----- From: Memovich, Gary [mailto:GARY.MEMOVICH@kla-tencor.com] Sent: 19 July 2001 18:53 To: Simon Peyton-Jones Subject: Haskell 98 report problem re lexical structure. Hello, I've been studying the Haskell 98 report and think there are a few problems in the section on lexical structure. First, the difference between "lexeme" considered as a production in the grammar and "lexeme" used in the more general sense is very confusing. The fact that "lexeme" as a grammar production is only distinguished by being in italic font is easy to overlook. Also, no definition of "lexeme" in the general sense, is given. I gather that strings matching the productions "dashes", "opencom", and "closecom" are all considered lexemes, but that strings matching "comment" and "ncomment" are not. But this is not explicitly stated anywhere. Also the string "---", for example, matches both the productions "varsym" and "dashes", so the fact that it should be considered the beginning of a comment is not decided by the maximal-munch rule alone. Perhaps the definition of "varsym" should explicitly rule out strings matching "dashes" in the same way it rules out strings matching "reservedop". As a second issue, it is stated at the end of section 2.2 that characters not in the category "ANY" are not valid in Haskell programs. But the productions "return", "linefeed", and "uniWhite", which are not included in the production "ANY", are explicitly included in the production "whitechar" which implies that they can be used in programs, at least in a limited way. I recently posted a message to the Haskell mailing list that was related to some of these same issues, but I now consider that message obsolete. Thanks for your time and attention, -- Gary
Simon Peyton-Jones proposed:
1. I will use "lexeme" consistently to mean what the "lexeme" production means. That's good.
2. The place that "lexeme" is currently used inconsistently is in 2.3 (Comments) Here I propose to replace paras 2 and 3 thus:
"An ordinary comment begins with a sequence of two or more consecutive dashes (e.g. --) and extends to the following newline. The sequence of dashes must not be the prefix of a legal lexeme. For example,
Any number of dashes is a prefix of a legal lexeme. You want to talk about what follows, but this formulation is about what might follow. (Or at least, that's how I understand it.) How about something like: The sequence of dashes must not be followed by another symbol, for example --> or --| do not begin a comment, they are just ordinary lexemes.
5. [Re Christian S's proposal, which I sent earlier, remove "opencom" from "lexeme"]
That is consisted with the other change you suggested in 2., and indeed a nicer way to be so. The second sentence in 5.5.1 reads Since qualifier names are part of the lexical syntax, no spaces are allowed between the qualifier and the name. I think this should be Since qualified names... ^ and could as well be Since qualified names are lexemes, no spaces are allowed... All the best Christian Sievers
participants (2)
-
Christian Sievers -
Simon Peyton-Jones