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 |
>>
>> 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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
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 > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
>
> 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. probably. at least digitValue: was fixed in the process. > 2) is acceptable, but I wouldn't do it. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
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 > _______________________________________________ Pharo-project mailing list [hidden email] 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 <[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 > Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Nicolas Cellier
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 > [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 |
Free forum by Nabble | Edit this page |