On Wed, May 04, 2016 at 07:29:05PM -0400, David T. Lewis wrote:
> On Wed, May 04, 2016 at 02:02:43PM -0700, Eliot Miranda wrote:
> > 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.
> 
> 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.
> 

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 :-(

Dave