RE: lexical description problem in language report?
I agree with Thomas's suggestion:
a) Change the definition of lexeme
b) Move lexical discussion from 5.5.1 to 2.4
It also looks that Christian is correct in revising the details of (a).
Thomas, do you agree?
Would this resolve the various lexical issues?
Thanks for your help.
Simon
| -Original Message-
| From: Christian Sievers [mailto:[EMAIL PROTECTED]]
| Sent: 24 July 2001 20:45
| To: [EMAIL PROTECTED]
| Subject: Re: lexical description problem in language report?
|
|
| 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
___
Haskell mailing list
[EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: lexical description problem in language report?
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
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: lexical description problem in language report?
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-report-html/lexemes.html#sect2.2
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
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
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: [EMAIL PROTECTED] ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: lexical description problem in language report?
Memovich, Gary wrote:
> ... 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. ...
>
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...)
This might lead you to believe that qualified names are part of the
context-free syntax rather than the lexical syntax, and hence that
spaces are allowed in them. Qualified names are discussed briefly near
the end of section 2.4, but their lexical properties are not explained
here. Instead the reader is refered to section 5.3. This reference
probably meant to lead to 5.5.1, where the text makes it clear that
qualified names are part of the lexical syntax.
The same problem is present in Appendix B.
Suggestions: include qvarid, qconid in the production for lexeme. Move
the explanation of the lexical properties of qualified names from
section 5.5.1 to section 2.4.
Thomas Hallgren
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
lexical description problem in language report?
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
