The question is ��How should it work?�� How do we distinguish whether the character ��e�� (or ��E��) is a representation for the (decimal) number 14 or is a representation for ��what follows is an exponent��? For example, it is easy to recognize that the radix-based integer literal ��16rFF�� is the SmallInteger 255 and that the float literal ��1.23e3�� is 1230.0 (a SmallDouble in GemStone).

For some reason, Pharo allowed ��16ree�� to be the number 238 (permitting lowercase for hexidecimal digits) and has also allowed ��2r1.111e3�� to be the same as ��2r1111�� or 15 (permitting floating-point numbers to have a radix). This introduces an ambiguity in interpreting the character ��e�� (or ��E��)��is it a hexadecimal digit or is it an exponent identifier?

Enforce a uppercase and lowercase distinction (digit and exponent respectively);
Allow exponents on decimal (base ten) numbers only;
Interpret ��e�� as a hexadecimal digit if the radix is >= 15 (allowing exponents on lower bases); or
Develop a new syntax to introduce exponents.

I believe that #3 is the current approach, and could be seen as #2 relaxed to allow exponents on numbers with a radix of 2-14.

It seems to me that the primary value of exponents on non-decimal (base ten) numbers is to represent binary numbers (2r1e63 is more readable than 2r1000000000000000000000000000000000000000000000000000000000000000). It seems to me that the value of exponents on numbers with a base above 10 is less pronounced (16r1E15 is better than 16r1000000000000000, but only a bit better). Mostly, I��d assert that the value of exponents for radix 16 is not worth a new syntax (excluding #4 above).

On Sep 4, 2019, at 10:36 PM, ducasse <stepharo@netcourrier.com> wrote:

Hi nicolas

let us fix this :)

why 15r1.2e1 is not working?
why 15r1.2e1 is not equals to 15r1.2E1?
why would we need a new syntax?

Stef
On 5 Sep 2019, at 00:19, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:

Once upon a time, only uppercase letters were accpeted as extra digits (in base > 10) for both int and float

Then 15r1.2E1 was not 15r1.2e1, the later being = 15r12.E

Then it was considered better to understand hexadecimal numbers with lowercase too...
and alternate-base Float became ambiguous and were never fixed :(

This would deserve a new syntax, I don't know what makes sense, 15r1.2_e1 15r1.2#e1 ...
Changing Smalltalk syntax is among the most difficult decisions, expect outcry ;)
Maybe because it's too easy :)

Le jeu. 5 sept. 2019 �� 00:04, James Foster <Smalltalk@jgfoster.net> a ��crit :
14r1.2e1 "16.0"
15r1.2e1 ��1.195851851851852"

Does it make sense to have exponents for numbers that are not base 10? There are tests that have large exponents for binary numbers and we are not sure how to handle this in GemStone.

James