Re: Ambiguity of parsing numbers with underscores/methods

Luke Palmer wrote:
> On 8/16/05, Ingo Blechschmidt <iblech@xxxxxx> wrote:
>
> > Hi,
> >
> >    1_234;      # surely 1234
> >    1e23;       # surely 1 * 10**23
> >
> >    1._5;       # call of method "_5" on 1?
> >    1._foo;     # call of method "_foo" on 1?
> >
> >    1.e5;       # 1.0 * 10**5?
> >    1.efoo;     # call of method "efoo" on 1?
> >    1.e_foo;    # call of method "e_foo" on 1?
> >
> >    0xFF.dead;  # call of method "dead" on 0xFF?
>
>
> I think we should go with the method call semantics in all of the
> ambiguous forms, mostly because "no such method: Int::e5" is clearer
> than silently succeeding and the error coming up somewhere else.
>
> Luke

    1.e5        # all of these...
    1._e5       #
    1._0e5      #
    1.e_0_5_    # == 1 * 10^5?

The longest-possible-token metarule, common among languages, would want 
all of these to be numbers.  I see that perl5's lexer has this rule (3rd 
edition, p49); is not perl6's specced to have it as well?

Likewise, if hex numbers allow fractions,

    0xDE_AD.BE_EF       # 57005.7458343505859375 ?
    0xde_ad.be_ef       # same

should be taken as a number.  (Naturally 'e' as exponent marker is here 
problematic.)

If one wants to call a method on a number, surely one may follow the 
usual advise and write
    1 ._5
    1 ._foo
    1 .efoo
    1 .e_foo
    0xFF .dead
?

-- Roger Hale