Re: lexical description problem in language report?
Thomas Hallgren wrote
There seems to be a similar problem with qualified identifiers. The production for lexeme includes varid, conid, etc, rather than qvarid, qconid, etc. (Perhaps someone forgot to update it when qualified names were introduced, in Haskell 1.3...)
Sorry we must have a different version of the report, but in my copy and also in the version on Simon PJ's web-pages section 2.4 (in the last paragraph) and appendix B include productions for the qualified identifiers. Wolfgang -- Wolfgang Lux Phone: +49-251-83-38263 Institut fuer Wirtschaftinformatik FAX: +49-251-83-38259 Universitaet Muenster Email: wlux@uni-muenster.de
Wolfgang Lux wrote:
Thomas Hallgren wrote
There seems to be a similar problem with qualified identifiers. The production for lexeme includes varid, conid, etc, rather than qvarid, qconid, etc.
Sorry we must have a different version of the report, but in my copy and also in the version on Simon PJ's web-pages section 2.4 (in the last paragraph) and appendix B include productions for the qualified identifiers.
The version of the report I looked in is here: http://research.microsoft.com/Users/simonpj/haskell98-revised/haskell98-repo... which is probably the same one you have, so it seems I need to clarify what I wrote. Although qualified names are listed in section 2.4,and in appendix B, the two first productions of the grammar are: program -> {lexeme | whitespace } lexeme -> varid | conid | varsym | consym | literal | special | reservedop | reservedid There is no reference to qualified names here. I thought the purpose of these productions were to say that a Haskell program is correct on the lexical level iff there is a derivation of it in the lexical grammar, starting from the nonterminal "program". Since qualified names are not part of this grammar, they are not part of the lexical syntax, which contradicts the text in section 5.5.1. So, I repeat my improvment suggestions: include qvarid, qconid, etc, in the production for lexeme. Move the explanation of the lexical properties of qualified names from section 5.5.1 to section 2.4. Regards, Thomas Hallgren
Thomas Hallgren wrote:
program -> {lexeme | whitespace } lexeme -> varid | conid | varsym | consym | literal | special | reservedop | reservedid
There is no reference to qualified names here. I thought the purpose of these productions were to say that a Haskell program is correct on the lexical level iff there is a derivation of it in the lexical grammar, starting from the nonterminal "program". Since qualified names are not part of this grammar, they are not part of the lexical syntax, which contradicts the text in section 5.5.1.
So, I repeat my improvment suggestions: include qvarid, qconid, etc, in the production for lexeme. Move the explanation of the lexical properties of qualified names from section 5.5.1 to section 2.4.
You could still parse a qualified name as three lexemes. Of course you don't want this, as this would allow white space between them. For the same reason, you want backquoted functions and constructors to be only one lexeme. In order to achieve this, just use qop instead of qvarsym and qconsym. And we need opencom, as the report says {- is a lexeme. So I suggest: lexeme -> qvarid | qconid | qop | literal | special | reservedop | reservedid | opencom It's all not new. See: http://www.dcs.gla.ac.uk/mail-www/haskell/msg01596.html http://www.dcs.gla.ac.uk/mail-www/haskell/msg01730.html All the best Christian Sievers
On Tue, Jul 24, 2001 at 10:50:16AM -0700, Thomas Hallgren wrote:
Although qualified names are listed in section 2.4,and in appendix B, the two first productions of the grammar are:
program -> {lexeme | whitespace } lexeme -> varid | conid | varsym | consym | literal | special | reservedop | reservedid
There is no reference to qualified names here. I thought the purpose of these productions were to say that a Haskell program is correct on the lexical level iff there is a derivation of it in the lexical grammar, starting from the nonterminal "program".
Similarly, in 4 and 4.4.2, we have gendecl -> fixity [digit] ops but digit isn't in the list of lexemes in 2.2 and B.2, nor is it reasonable for it to be there. I suggest gendecl -> fixity [integer] ops with the value of the integer constrained to be between 0 and 9 inclusive. Incidentally, this is what GHC, Hugs and NHC do, in that they accept infix 0x0003 !$% as equivalent to infix 3 !$% presumably because doing what the Report says would be rather awkward.
participants (4)
-
Christian Sievers -
Ross Paterson -
Thomas Hallgren -
Wolfgang Lux