On Tue, 11 Jul 2000, John Hawkinson wrote:

> | Fix for:
> | 
> | 7.      Numbers starting with [a-f] should work, but symbols
> | 	  of the same name should have priority.
> 
> Sorry to be a wet blanket about this.
> 
> Did you have a reason for implementing this as you did, instead
> of having the lexer return tNUMBER for numbers starting with [a-f]
> (now it returns tIDENT and you special-case failed identifiers
> by looking to see if they can be parsed into numbers).
> 
> I think I would have had tNUMBER returned and then attempt to translate
> all tNUMBER cases into identifiers before trying them as numbers.

Since lexical analysis is separate from semantic analysis, this was the
way to do it with the least impact.  Otherwise we would need to do the
symbol lookup inside the lexical analyzer, something that would require a
major overhaul on the ddb input processing code.

> Corner cases:
> 
>        a)	A symbol named "1234" will be interpreted as 0x1234 and
> 		not it's real value, but a symbol named "f234" will be
> 		properly identified. That seems wrong.

No change from current behavior.

>        b)	In what I propose "0xf234" would be lexed as tNUMBER
> 		and some special handling would be required for 
> 		be required for db_term() to tell the difference.

	 c)	If the radix is octal and there are numbers > 7 the
		new converter routine will still silently convert them
		incorrectly (not switch base).

> 
> Regardless, I would judge that this is enough of a user-visible change
> as to merit a doc/CHANGES entry; but I'd hold off until we're solid
> on the implementation.

You cannot distinguish a tNUMBER from a tIDENT without doing a symbol
lookup.  What I did was a quick implementation to fix a problem that has
been bothering me for so long that I finally couldn't bear it any
more.  If you have the time to revamp DDB's input routines, be my guest.

Eduardo Horvath