[squeak-dev] Re: 16rff broke 16r8e7

Andreas Raab andreas.raab at gmx.de
Sun Feb 14 23:12:57 UTC 2010


Hi Nicolas -

I've probably made my opinion clear enough earlier, but in case someone 
missed it, I'm all for option #2. The reason being that I've repeatedly 
copied hex constants and the need to rewrite those in upper case has 
driven me insane more than once (and I've made several errors in the 
process since the e notation gets silently accepted). Contrary to which 
I have never seen even a single use case for radix and exponent notation 
together.

Cheers,
   - Andreas


Nicolas Cellier wrote:
> As you may know, with 16rff change, we cannot anymore use a radix
> notation combined with an exponent notation.
> At least for base > 14, the exponent letter is taken as an ordinary digit.
> The options are:
> 
> 1) revert the change
> 
> 2) abandon combined radix+exponent notation
> all the code for printing Float with different radix, and also for
> scanning can be removed
> Or I can provide a subclass of SqNumberParser for backward compatibility.
> 
> 3) find a new syntax for radix+exponent
> 
> For example, 16r7f_e6 16r7f^6 16r7f#6
> None of these is ambiguous with existing code.
> 
> Or maybe use an uppercase R for uppercase only digits...
> 
> 4) use q exponent to at least enable base 16
> This is hackish and not universal, but I guess hardly anybody ever
> used a base > 16.
> 
> -------------------------------------
> 
> What would squeak/pharo folks choose ?
> 
> -------------------------------------
> Personnally, I'm OK with 1) and 2).
> But 2) deserves a bit more discussion
> After all this is a change of Squeak syntax.
> I find Dan's notation educative and fun, especially for writing tests.
> But it is a non portable Squeakish thing, rarely used, and it does not
> really has much value for industrial usage,
> On the other hand, is it really necessary to parse 16rff ?
> 
> I dislike 3) because I find my own propositions bad.
> Also, if we remove Squeak-specific syntax for compatibility reasons,
> why the hell adding a new uncompatible syntax?
> Previous usage of e notation was far better because just extending an
> existing syntax, not creating a new one.
> Maybe you'll have other ideas...
> 
> Nicolas
> 
> -------------------------------------
> 
> 




More information about the Squeak-dev mailing list