-----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-----