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 -
> >
> >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20160506/75b67e5e/attachment.htm