>> 
>> 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.
> 
> do you know how this is handled in VW?
> 
> Stef
> 
>> 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 be the example
>> 
>> -------------------------------------
>> 
>> 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,
> 
> I read the mail than juan mentioned but I could not understand or I read another one :)
> 
>> On the other hand, is it really necessary to parse 16rff ?
> 
> sounds like?
> 
>> 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?
> 
> Yes 
> what does our wonderful ANSI standard mentions?
> 
>> 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...
> 
> Stef