[Pharo-project] 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. 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 -------------------------------------
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
2010/2/14 Stéphane Ducasse <stephane.ducasse@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Sun, 14 Feb 2010, Nicolas Cellier wrote:
2010/2/14 Stéphane Ducasse <stephane.ducasse@inria.fr>:
what does our wonderful ANSI standard mentions?
Base 2 to 36 with letter A to Z. Nothing about a-z. But nothing against it.
At 3.5.6 the BNF allows only uppercase letters (uppercaseAlphabetic). Lowercase letters are not valid. Levente
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Sun, 14 Feb 2010, 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...
I'd go for 1). Squeak extends the ANSI standard one way, while VW does in another. If you want portable code, use the standard compatible syntax: 16rFF. 2) is acceptable, but I wouldn't do it. Levente
Nicolas
-------------------------------------
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
http://code.google.com/p/pharo/issues/detail?id=2068 On Feb 14, 2010, at 9:22 PM, 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
-------------------------------------
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (3)
-
Levente Uzonyi -
Nicolas Cellier -
Stéphane Ducasse