On Wed, May 4, 2016 at 5:37 AM, Bert Freudenberg <bert at freudenbergs.de>
wrote:

>
> > On 04.05.2016, at 13:32, Tobias Pape <Das.Linux at gmx.de> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20160504/7547e0b9/attachment.htm