To disambiguate, we need two different syntaxes: One for uppercase  
digits with $e, $s etc suffixes, and one for caseless digits and no  
suffixes.

One of them might be the one we have now. We might keep it for case  
insensitive integers: 16rFFe2 = 16rFFE2 = 16rffe2 = 65506.

The other one could be use $q instead of $r: '16qFFe2' could mean  
'16rFF00'or 65280.

Or alternatively, acknowledge that the prefix '16r' is arbitrarily in  
decimal. This is something I never liked. A better way to say radix  
sixteen could be to express it in a single digit. So a decimal number  
could be 'Ar256', and 'GrFFE2' would be 65506 while 'GrFFe2' could be  
65280.

I prefer the latter, although it might need more explaining.

Regards,
Juan Vuletich

Quoting Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>:

> 2016-05-06 17:01 GMT+02:00 Eliot Miranda <eliot.miranda at gmail.com>:
>
>> Hi Bert, Hi All,
>>
>> > On May 6, 2016, at 5:24 AM, Bert Freudenberg <bert at freudenbergs.de>
>> wrote:
>> >
>> >> On 06.05.2016, at 10:21, Stéphane Rollandin <lecteur at zogotounga.net>
>> wrote:
>> >>
>> >>> After taking a closer look at how the parsing needs to work, I see that
>> >>> fixing this (by issuing a warning) may be easier said than done. Maybe
>> that's
>> >>> why no one has fixed it yet :-(
>> >>
>> >> But is it really a problem ? It arises only because one abuses syntatic
>> sugar and can be fixed by writing
>> >>
>> >> {
>> >> 25rFFs2.
>> >> 26rFFs2.
>> >> 27rFFs2.
>> >> 28rFFs2.
>> >> 29rFFs2.
>> >> 30rFFs2.
>> >> 31rFFs2.
>> >> 32rFFs2
>> >> }
>> >>
>> >> instead.
>> >>
>> >> Stef
>> >
>> > Writing it that way does not make any difference. Some of these are
>> parsed as ScaledDecimal, some as Integer. That is surprising, unexpected,
>> and potentially leads to bugs.
>> >
>> > Dan designed the number parsing to be context-independent. Uppercase
>> letters were digits in bases > 10, certain lowercase letters have special
>> meaning (r, e, d, q, s). This leads to a rather simple syntax.
>> >
>> > When we made the change to allow lower-case letters for digits, number
>> parsing became ambiguous. That’s why the result of the expression above is
>> surprising, because the parsing rules are no longer simple and universal,
>> but depend on the radix.
>> >
>> > The only compelling reason for introducing the change was to allow
>> lower-case hex numbers (as Eliot pointed out).
>> >
>> > How about we special-case radix 16, to be the only one that allows
>> lowercase digits for plain integers? In general we would only allow
>> uppercase digits, and the lowercase special modifiers. But if the radix was
>> 16, the rest of the number would be parsed as an case-independent hex
>> integer without modifiers.
>>
>> +1
>>
>> >
>> > Another idea would be to allow 0x as a modifier (similar to 16r) to
>> indicate a hex integer with both upper and lower-case digits.
>>
>> Please no.  It's convenient but a horrible wart on the side in an elegant
>> syntax.
>> >
>> > I actually like the latter, the only problem would be that code using
>> lower-case hex numbers would have to be rewritten.
>>
>> How about trying to add code to the compiler's error handling to auto
>> convert 0x form C hex into Smalltalk syntax?  0x0 gets parsed as 0 x 0,
>> which is a syntax error, so once spotted, adding a bulk edit that does look
>> for 0x[0-9A-Fa-f]+ shouldn't be too hard.
>>
>>
> I'm not at all convinced by a warning, nor fond of 0x which is terribly
> limited
> (we could allow 0x in specialized parser, maybe ExtendedParser but may be
> not in Smalltalk parser).
>
> What would be much nicer is the possibility to clearly separate the
> exponent or scale specification.
> For example something like 32rFF_s2 or 16r1.0_e1.
> Underscore would sound a good candidate, unless we keep it for thousand
> separator 1_400_000?
> # is another candidate, 16r1.0#e1
>
> But it means changing Smalltalk syntax...
>
>
>
>> >
>> > - Bert -
>> >
>> >
>> >
>> >
>>
>>