RE: Ambiguity of parsing numbers with underscores/methods
Larry Wall wrote: Yes, that's a convenient escape. But really, arguments from principle aside, the underlying question is what someone will see if they look at 1.e5, and I suspect most people will see a number with an exponent. This is a spot where Ruby violates Least Surprise, at least for people who aren't used to seeing methods hanging off of literals. To the original point, I have to seriously question the usefulness of invoking ambiguously named methods on numeric literals... 1e5 # number 1.0e5# number (1).e5 # method call, since you really mean it The decimal point without a fractional part looks bizarre to me: 1.e5 # syntax error Surely +. and -. are invalid syntax? (\.\d+)? , not (\.\d*)? . -- Gordon Henriksen [EMAIL PROTECTED]
Re: Ambiguity of parsing numbers with underscores/methods
Luke Palmer wrote: On 8/16/05, Ingo Blechschmidt [EMAIL PROTECTED] 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
Re: Ambiguity of parsing numbers with underscores/methods
On Tue, Aug 16, 2005 at 16:59:12 -0400, Mark Reed wrote:
On 2005-08-16 16:45, Nicholas Clark [EMAIL PROTECTED] wrote:
I'd find it hard defending a language that treated 1.e5 as a method call.
Guess we shouldn't sign you up for the Ruby Defense League, then?
irb(main):001:0 1.e5
NoMethodError: undefined method `e5' for 1:Fixnum
from (irb):1
irb(main):002:0
Well, I think the only sane alternative is to implement AUTOMETHOD
on int that makes it a float:
method AUTOMETHOD {
# parse scientific notation of method name (e.g. e5),
# and apply it to the invocant, returning a float
}
There, no ambiguity.
--
() Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker
/\ kung foo master: /me spreads pj3Ar using 0wnage: neeyah!!!
pgpTcztTCimYb.pgp
Description: PGP signature
Re: Ambiguity of parsing numbers with underscores/methods
On Tue, Aug 16, 2005 at 05:25:40PM -0400, Roger Hale wrote: : 1.e5# all of these... : 1._e5 # : 1._0e5 # : 1.e_0_5_# == 1 * 10^5? The last three are illegal because underline is allowed only between digits. : 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? If it's not a metarule, it's at least a metametarule. : 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.) It's a problem even without fractions. I expect we can just disallow the exponent at that point and rely on constant folding. Or maybe there's some colon trickery we can do, so the general form might be something like: 16:abcd.ef:+23. (I'm presuming the exponent is always decimal, like the radix.) Of course, then someone will suggest that infix :+ means * 10 ** and we get things like $foo:+23. So maybe we should come up with a better way to write that and then just go the constant folding route. 16:abcd.ef*e(23) maybe, if you don't mind clobbering the e() function. But we can always stick with 16:abcd.ef*10**23. The situation probably doesn't arise often enough to justify syntactic sugar. I suppose I could just barely see dropping the 10 there to get 16:abcd.ef***23, but then we'd have to put up with $foo ***= 23; : 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 : ? Yes, that's a convenient escape. But really, arguments from principle aside, the underlying question is what someone will see if they look at 1.e5, and I suspect most people will see a number with an exponent. This is a spot where Ruby violates Least Surprise, at least for people who aren't used to seeing methods hanging off of literals. Larry
Re: Ambiguity of parsing numbers with underscores/methods
On Wed, Aug 17, 2005 at 11:37:26AM -0700, Larry Wall wrote: On Tue, Aug 16, 2005 at 05:25:40PM -0400, Roger Hale wrote: : 1.e5# all of these... : 1._e5 # : 1._0e5 # : 1.e_0_5_# == 1 * 10^5? The last three are illegal because underline is allowed only between digits. ...yet Perl5 accepts them. So Perl6 is more restrictive? (Which is good, because that's how Pugs currently implements them) Thanks, /Autrijus/ pgpTQGinWkn5k.pgp Description: PGP signature
Re: Ambiguity of parsing numbers with underscores/methods
On Thu, Aug 18, 2005 at 02:40:12AM +0800, Autrijus Tang wrote: : On Wed, Aug 17, 2005 at 11:37:26AM -0700, Larry Wall wrote: : On Tue, Aug 16, 2005 at 05:25:40PM -0400, Roger Hale wrote: : : 1.e5# all of these... : : 1._e5 # : : 1._0e5 # : : 1.e_0_5_# == 1 * 10^5? : : The last three are illegal because underline is allowed only between : digits. : : ...yet Perl5 accepts them. So Perl6 is more restrictive? Yes. Larry
Re: Ambiguity of parsing numbers with underscores/methods
On 8/16/05, Ingo Blechschmidt [EMAIL PROTECTED] 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
Re: Ambiguity of parsing numbers with underscores/methods
On Tue, Aug 16, 2005 at 08:36:19PM +, Luke Palmer wrote: On 8/16/05, Ingo Blechschmidt [EMAIL PROTECTED] 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. To me, 1.e5 is not ambiguous. But maybe I've had too much dealing with floating point in a previous life. I'd find it hard defending a language that treated 1.e5 as a method call. Nicholas Clark
