-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Er,
> For the purpose of warnings, I would explicitly keep track, for
> unqualified operator "-", whether it was followed by a digit (which is
> the unique and certain determiner that a numeric literal follows. Octal
> and hexadecimal start with 0c for some "c" and floating-point always
> starts with a decimal digit). This would probably involve adding an
> argument isomorphic to Bool to the constructor "ITminus". Then in
> compiler/parser/Lexer.x just before the @varsym rule (since alex is
> first maximal-munch, then top-to-bottom in the .x file, in matching
> choice), add rules
> "-" / [0-9] { minus followed by number }
> "-" { minus not followed by number }
> ( the [0-9] pattern could be refined perhaps... )
> Then this notation has to be carried on through the Parser.y, which
> shouldn't be too hard.
>
> For negative numeric literals, I think extra rules in the lexer would be
> added, '-' followed by the various numeric literal types (this seems a
> little repetitious, is there an easier way?). The varieties of literals
> that were standard in the first place (i.e. non-unboxed) will get " / {
> extension is on }" qualifications to their patterns. mkHsNegApp (in
> RdrHsSyn.lhs) will be simplified or removed, since we are moving towards
> a more sensible treatment of negative literals. Another implementation
> choice could be to recognize the "minus followed by number" in the
> parser, but then it might be hard to distinguish between '98-syntax
> negate, subtraction, and negative unboxed literals, without ambiguity in
> the parser?
When the "new" syntax is switched on, assuming this includes removing
"-" as general prefix negate, ITminus would always be not followed by a
number (by design; those become single negative-number tokens).
Furthermore, we don't really want to treat "-" specially in this case.
So I guess the rule
> "-" { minus not followed by number }
should be more like
"-" / { not "new" syntax } { minus not followed by number }
, and the case that interprets "..", "=>", "->", etc. would have its "-"
case removed (whether "new" syntax or not).
The only this this "don't treat '-' specially in this case" might fall
afoul of is this proposed warning option:
> If a "-" isn't followed immediately by a numeric literal, the only
> thing to watch out for (and warn about) is the "forbidden section"
> (- 1), which could mean an actual section (\x -> x - 1) in the "new"
> syntax.
, if it proves difficult to detect at the appropriate point whether an
infix-operator was written as the unqualified "-".
Isaac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGHsG+HgcxvIWYTTURAl7sAJsFFNEcjTA6l5iPSwSqbx8zs6IkSQCcCyJY
F2ng1MXJ0WN1v2scSDe72gM=
=JHlF
-----END PGP SIGNATURE-----
_______________________________________________
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
