16rff broke 16r8e7

>>
>> 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

> 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
>
> -------------------------------------
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

>>
>>> 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
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> 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
>
> -------------------------------------
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project