[squeakdev] Re: [Pharoproject] 16rff broke 16r8e7
Stéphane Ducasse
stephane.ducasse at inria.fr
Sun Feb 14 20:48:14 UTC 2010
>>
>> 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 Squeakspecific 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
More information about the Squeakdev
mailing list
