Misleading error message for underscore patterns
Not really a bug, but a confusion from a misleading error message. This was seen using nhc98 1.18 on Mac OS X 10.4.1. The following code contains underscore identifier patterns which are accepted by nhc98 when the -98 option is given: foo _2a = 1 bar (T a _2b) = 1 (I don't have the H98 definition handy but I'm presuming that nhc is correct in allowing these patterns in H98.) However, when -98 is not present, errors are reported that are misleading in that they refer to the "foo" and "bar" tokens, not the bad patterns, and they don't complain about the patterns at all: 3:1-3:3 Found foo but expected a {-end-of-definition-or-EOF-} 5:1-5:3 Found bar but expected a {-end-of-definition-or-EOF-} As the bar example illustrates, the actual error could be arbitrarily far away from the position in the message. Tony
Tony Sloane
Not really a bug, but a confusion from a misleading error message. The following code contains underscore identifier patterns which are accepted by nhc98 when the -98 option is given:
foo _2a = 1 bar (T a _2b) = 1
(I don't have the H98 definition handy but I'm presuming that nhc is correct in allowing these patterns in H98.)
Yes, these patterns are legal H'98. It is wrong that nhc98 should complain about them when the -underscore flag is off (the default, except with -98).
However, when -98 is not present, errors are reported that are misleading in that they refer to the "foo" and "bar" tokens, not the bad patterns, and they don't complain about the patterns at all:
3:1-3:3 Found foo but expected a {-end-of-definition-or-EOF-} 5:1-5:3 Found bar but expected a {-end-of-definition-or-EOF-}
Yes, the lexical error is being transformed into a parse error, which is indeed confusing. This is easily fixed though. A patch is attached, and will appear in CVS shortly. Regards, Malcolm
participants (2)
-
Malcolm Wallace -
Tony Sloane