Parsing Numbers

Andreas Raab andreas.raab at gmx.de
Sun Sep 18 00:17:10 UTC 2005


David T. Lewis wrote:
> Well, if you can accept that "(2 + 3 * 4) ~= (2 + (3 * 4))", you should
> not be deeply disturbed to find that "16r1E4 ~= 16r1e4".

If you'd know me a little better, you would probably know that the 
unfortunate effect that "(2 + 3 * 4) ~= (2 + (3 * 4))" disturbs me 
deeply, too. It's simply bad user interface design to ignore what your 
users already know and have been growing up with. And no, you don't have 
to "accept" it if you know what you're doing since you can use 
parenthesis and reordering. For example, I tend to write linear 
interpolation as "(end - start) * t" although the parens aren't 
required. But at times the precedence rules *still* get me, even after 
using Smalltalk for more than ten years. And I tend to use *more* 
parenthesis rather than *less* as some might expect, since I do happen 
to look at and use other languages which get precedence right and it 
confuses the hell out of me to switch between precedence rules.

> This appears to
> be a well established convention for Smalltalk (it works that way in e.g.
> Squeak 2.4).  It does have a nice internal consistency, and the behavior
> is well defined (albeit not well enough documented).

And because Smalltalk is the holy cow we can't possibly change anything. 
Yes, I know. I've heard that tune so often... but anyways, I'll give it 
one more shot: How about compatibility? In VisualWorks, for example, it 
is indeed the fact that "16r1E4 = 16r1e4". Wouldn't it be nice if hex 
constants written in VisualWorks can be *correctly* read into Squeak?

Regards,
   - Andreas



More information about the Squeak-dev mailing list