Code Jeopardy

> -----Original Message-----
> From: [hidden email] [mailto:squeak-dev-
> [hidden email]] On Behalf Of Tobias Pape
> Sent: Wednesday, May 04, 2016 7:33 AM
> To: The general-purpose Squeak developers list
> Subject: [squeak-dev] Code Jeopardy
>
> Hi all,
>
> without executing, what does the following expression result in?
>
> #(
> 25rFFs2
> 26rFFs2
> 27rFFs2
> 28rFFs2
> 29rFFs2
> 30rFFs2
> 31rFFs2
> 32rFFs2
> )
>
> Best regards
> -Tobias

> hmmm
>
> It's an array.  It looks like encoded numbers base 25 through 32 of hex FF
> but not sure about the s2.  Because I'm not sure the numbers will evaluate
> it could just error.  But let's say I'm wrong and this is something that
> actually does work and I haven't seen it before, base 25-32 FF s2
> something,
> this will return an array of numbers.
>
> Not executing it was difficult :).  Looking forward to the answer.
>
> All the best,
> Ron Teitelbaum
>
>> -----Original Message-----
>> From: [hidden email] [mailto:squeak-dev-
>> [hidden email]] On Behalf Of Tobias Pape
>> Sent: Wednesday, May 04, 2016 7:33 AM
>> To: The general-purpose Squeak developers list
>> Subject: [squeak-dev] Code Jeopardy
>>
>> Hi all,
>>
>> without executing, what does the following expression result in?
>>
>> #(
>> 25rFFs2
>> 26rFFs2
>> 27rFFs2
>> 28rFFs2
>> 29rFFs2
>> 30rFFs2
>> 31rFFs2
>> 32rFFs2
>> )
>>
>> Best regards
>> -Tobias
>
>
>

> On Wed, May 4, 2016 at 5:37 AM, Bert Freudenberg <[hidden email]>
> wrote:
>
> >
> > > On 04.05.2016, at 13:32, Tobias Pape <[hidden email]> wrote:
> > >
> > > Hi all,
> > >
> > > without executing, what does the following expression result in?
> > >
> > > #(
> > > 25rFFs2
> > > 26rFFs2
> > > 27rFFs2
> > > 28rFFs2
> > > 29rFFs2
> > > 30rFFs2
> > > 31rFFs2
> > > 32rFFs2
> > > )
> > >
> > > Best regards
> > >       -Tobias
> >
> >
> > Interesting.
> >
> > 16rFFe4 used to be 16711680, now it???s 65508.
>
>
>
> >
> > VisualWorks suffers exactly the same issue:
>
> #(390 #s2 405 #s2 420 #s2 435 #s2 379264 419342 462150 507778)
>
> The only thing we can do is issue a warning, because otherwise we ban legal
> programs.  But we also need to disambiguate.  Should s or e in the
> penultimate positions force interpretation as scaled decimal or exponent,
> and hence force someone using a base >= 15 to use upper case?  Seems the
> only practical choice to me.  So we need tests and to modify printing.  At
> least we still print in upper case.

>
> And BTW, I for one would hate having to enter hex constanrts in upper
> case.  Makes my VMMaker life much more difficult; all the disassemblers and
> debuggers I use print hex in lower case.
>
>
>
>
>
> > Try these:
> >
> > #(
> > 10r1e4
> > 11r1e4
> > 12r1e4
> > 13r1e4
> > 14r1e4
> > 15r1e4
> > 16r1e4
> > 17r1e4
> > 18r1e4
> > )
> >
>
> VW refuses to parse these (non-decimal integers cannot have exponents, and
> if one adds a decimal point, non-radix 10 numbers cannot contain a decimal
> point.
>
>
> > Maybe we need to raise an error for certain combinations? Better than a
> > surprise.

> On Wed, May 04, 2016 at 02:02:43PM -0700, Eliot Miranda wrote:
> > On Wed, May 4, 2016 at 5:37 AM, Bert Freudenberg <[hidden email]>
> > wrote:
> >
> > >
> > > > On 04.05.2016, at 13:32, Tobias Pape <[hidden email]> wrote:
> > > >
> > > > Hi all,
> > > >
> > > > without executing, what does the following expression result in?
> > > >
> > > > #(
> > > > 25rFFs2
> > > > 26rFFs2
> > > > 27rFFs2
> > > > 28rFFs2
> > > > 29rFFs2
> > > > 30rFFs2
> > > > 31rFFs2
> > > > 32rFFs2
> > > > )
> > > >
> > > > Best regards
> > > >       -Tobias
> > >
> > >
> > > Interesting.
> > >
> > > 16rFFe4 used to be 16711680, now it???s 65508.
> >
> >
> >
> > >
> > > VisualWorks suffers exactly the same issue:
> >
> > #(390 #s2 405 #s2 420 #s2 435 #s2 379264 419342 462150 507778)
> >
> > The only thing we can do is issue a warning, because otherwise we ban legal
> > programs.  But we also need to disambiguate.  Should s or e in the
> > penultimate positions force interpretation as scaled decimal or exponent,
> > and hence force someone using a base >= 15 to use upper case?  Seems the
> > only practical choice to me.  So we need tests and to modify printing.  At
> > least we still print in upper case.
>
> Given that most of us are not using base 32 arithmetic on a regular basis,
> issuing a warning seems like a reasonable thing to do. In practice, the
> problem would only arise when parsing numbers. Given a suitable warning,
> the source of that data could presumably be edited in some way to avoid
> the ambiguity.
>
> A warning might be annoying, but it would be better than permitting numeric
> data to be interpreted in unexpected ways.
>

> On May 6, 2016, at 5:24 AM, Bert Freudenberg <[hidden email]> wrote:
>
>> On 06.05.2016, at 10:21, Stéphane Rollandin <[hidden email]> 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.

> 2016-05-06 17:01 GMT+02:00 Eliot Miranda <[hidden email]>:
>
>> Hi Bert, Hi All,
>>
>> > On May 6, 2016, at 5:24 AM, Bert Freudenberg <[hidden email]>
>> wrote:
>> >
>> >> On 06.05.2016, at 10:21, Stéphane Rollandin <[hidden email]>
>> 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 -
>> >
>> >
>> >
>> >
>>
>>

>> {
>> 25rFFs2.
>> 26rFFs2.
>> 27rFFs2.
>> 28rFFs2.
>> 29rFFs2.
>> 30rFFs2.
>> 31rFFs2.
>> 32rFFs2
>> }
>>
>> instead.
>>
>> Stef
>
> Writing it that way does not make any difference.