<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2016-05-06 17:01 GMT+02:00 Eliot Miranda <span dir="ltr"><<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Bert, Hi All,<br>
<span class=""><br>
> On May 6, 2016, at 5:24 AM, Bert Freudenberg <<a href="mailto:bert@freudenbergs.de">bert@freudenbergs.de</a>> wrote:<br>
><br>
>> On 06.05.2016, at 10:21, Stéphane Rollandin <<a href="mailto:lecteur@zogotounga.net">lecteur@zogotounga.net</a>> wrote:<br>
>><br>
>>> After taking a closer look at how the parsing needs to work, I see that<br>
>>> fixing this (by issuing a warning) may be easier said than done. Maybe that's<br>
>>> why no one has fixed it yet :-(<br>
>><br>
>> But is it really a problem ? It arises only because one abuses syntatic sugar and can be fixed by writing<br>
>><br>
>> {<br>
>> 25rFFs2.<br>
>> 26rFFs2.<br>
>> 27rFFs2.<br>
>> 28rFFs2.<br>
>> 29rFFs2.<br>
>> 30rFFs2.<br>
>> 31rFFs2.<br>
>> 32rFFs2<br>
>> }<br>
>><br>
>> instead.<br>
>><br>
>> Stef<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> The only compelling reason for introducing the change was to allow lower-case hex numbers (as Eliot pointed out).<br>
><br>
> 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.<br>
<br>
</span>+1<br>
<span class=""><br>
><br>
> 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.<br>
<br>
</span>Please no. It's convenient but a horrible wart on the side in an elegant syntax.<br>
<span class="">><br>
> I actually like the latter, the only problem would be that code using lower-case hex numbers would have to be rewritten.<br>
<br>
</span>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.<br>
<br></blockquote><div><br></div><div>I'm not at all convinced by a warning, nor fond of 0x which is terribly limited<br></div><div>(we could allow 0x in specialized parser, maybe ExtendedParser but may be not in Smalltalk parser).<br><br></div><div>What would be much nicer is the possibility to clearly separate the exponent or scale specification.<br></div><div>For example something like 32rFF_s2 or 16r1.0_e1.<br></div><div>Underscore would sound a good candidate, unless we keep it for thousand separator 1_400_000?<br></div><div># is another candidate, 16r1.0#e1<br></div><div><br></div><div>But it means changing Smalltalk syntax...<br></div><div><br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
><br>
> - Bert -<br>
><br>
><br>
><br>
><br>
<br>
</blockquote></div><br></div></div>