16rff broke 16r8e7
Locked
 
|
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 ------------------------------------- |
Re: [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. > > 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 |
Re: [Pharo-project] 16rff broke 16r8e7
|
|
In reply to this post by Nicolas Cellier
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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > |
Re: [Pharo-project] 16rff broke 16r8e7
|
|
In reply to this post by Stéphane Ducasse
2010/2/14 Stéphane Ducasse <[hidden email]>:
>>> >>> 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > |
Re: [Pharo-project] 16rff broke 16r8e7
|
|
On Sun, 14 Feb 2010, Nicolas Cellier wrote:
> 2010/2/14 Stéphane Ducasse <[hidden email]>: >>> 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 >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > |
|
|
Is there any provision to make this pluggable, for example, how easy
would it be for FixedDecimal to be added to the party. Keith |
|
|
In reply to this post by Nicolas Cellier
Hi Nicolas -
I've probably made my opinion clear enough earlier, but in case someone missed it, I'm all for option #2. The reason being that I've repeatedly copied hex constants and the need to rewrite those in upper case has driven me insane more than once (and I've made several errors in the process since the e notation gets silently accepted). Contrary to which I have never seen even a single use case for radix and exponent notation together. Cheers, - Andreas 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 > > ------------------------------------- > > |
Re: [Pharo-project] 16rff broke 16r8e7
|
|
In reply to this post by Stéphane Ducasse
Stéphane Ducasse wrote:
>> ... >> I read the mail than juan mentioned but I could not understand or I read another one :) What I added is support for stuff like 1r111 = 3 and 1r11111 = 5, just for fun, as Dan suggested. Cheers, Juan Vuletich |
|
|
In reply to this post by Nicolas Cellier
On Sun, Feb 14, 2010 at 09:22:55PM +0100, 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 ? > For the default behavior in Squeak, I prefer #1 for the reasons explained here (thanks to Bert for the reference): http://lists.squeakfoundation.org/pipermail/squeak-dev/2000-March/013368.html I also think that SqNumberParser enables some flexibility, and if it can be used to accept a more convenient another syntax (16rff) for the benefit of people doing serious data conversion and numeric work, this would be a very good thing. To me, the "micro world of simplicity and generality" idea is more important than syntactic convenience. Encouraging understanding and exploration is important, and the annoynance of having to write some extra data conversion code seems a small price to pay. Dave |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |