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

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Sun Feb 14 21:19:04 UTC 2010


2010/2/14 Stéphane Ducasse <stephane.ducasse at inria.fr>:
>>>
>>> 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

16rff is accepted
2r1e31 raise an Error explicitely stating exponent can't be mixed with
radix in VW

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

16r7Fq6

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

He has preserved Dan's extension.
16rff forbidden
16r7Fe6 = 16r7F000000

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

Base 2 to 36 with letter A to Z.
Nothing about a-z. But nothing against it.

In the rationale, 10e10 is not allowed (Squeak), nor 1.0q (VW)

>>
>>> 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
> Pharo-project at lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>



More information about the Squeak-dev mailing list