From @moritz

r31220​:

say 23_433
23433
say 23_433.4_4
error​:imcc​:syntax error, unexpected IDENTIFIER, expecting '\n' ('_433')
  in file 'EVAL_13' line 12
23

Obviously the underscores in the fractional part of the number needs to
be stripped by rakudo before emitting them as PIR.

Moritz

--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/

From @jnthn

On Thu Sep 18 00​:49​:59 2008, moritz@​casella.verplant.org wrote​:

r31220​:

say 23_433
23433
say 23_433.4_4
error​:imcc​:syntax error, unexpected IDENTIFIER, expecting '\n' ('_433')
in file 'EVAL_13' line 12
23

Obviously the underscores in the fractional part of the number needs to
be stripped by rakudo before emitting them as PIR.

Fixed in r31225. I was going to say add a test, but 6 just started
passing unexpectedly! :-)

Thanks,

Jonathan

The RT System itself - Status changed from 'new' to 'open'

@jnthn - Status changed from 'open' to 'resolved'

From @pmichaud

On Thu, Sep 18, 2008 at 03​:28​:31AM -0700, jnthn@​jnthn.net via RT wrote​:

On Thu Sep 18 00​:49​:59 2008, moritz@​casella.verplant.org wrote​:

r31220​:

say 23_433
23433
say 23_433.4_4
error​:imcc​:syntax error, unexpected IDENTIFIER, expecting '\n' ('_433')
in file 'EVAL_13' line 12
23

Obviously the underscores in the fractional part of the number needs to
be stripped by rakudo before emitting them as PIR.

Fixed in r31225. I was going to say add a test, but 6 just started
passing unexpectedly! :-)

Well, this is only "sorta fixed". The problem with the approach being
used now is that we're limited to floating point formats that IMCC understands
(which is a little different from the formats that Perl 6 understands).

What really should happen here is that we take the same approach that
is being done for Ints -- namely, collect the characters that make up
the floating point literal into a Str or Perl6Str, numify the
string to obtain the correct floating point value, and pass that
value directly to PAST.

Unfortunately, at present Parrot doesn't seem to have a convenient way to
convert floating point values back into PIR literals without losing
lots of precision (RT #​59006). Thus a float value like 2.71828182845905
coming from the HLL source ends up being written as 2.71828 in the PIR
output, which is wrong by about 0.00000182845905. Thus the current
code simply passes the string directly from the source to PIR
(stripping underscores after the r31225 patch). While this is a
reasonable workaround for now, it's not really the final answer we're
looking for.

I'm attaching RT #​59006 as a dependency for this ticket -- when that
ticket is resolved, we can truly fix this one.

Thanks!

Pm