Nothing profound here, just some fun syntax tricks for a Friday.

What is the output of the code below, and why?

my $foo = 12_123_1234_12_1; my $bar = "12_123_1234_12_1"; my $baz = 0 + $bar; print $foo, "\n"; print $bar, "\n"; print $baz, "\n";

"There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

Replies are listed 'Best First'.
Re: Fun with Numbers
by Tanktalus (Canon) on Feb 11, 2005 at 21:32 UTC

    You're mean. :-) So few people likely do that ... it's just plain mean.

    I got it right on my first guess (you'll have to take my word for that ;-}), although I had to run it through the interpreter just to be sure. It's still mean.

    As to why:

    the compiler ignores _ in numbers, but the string-to-number engine does not.

      I prefer the term "psychological aggression". The term "mean" has negative historical connotations.

      "There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

Re: Fun with Numbers
by Joost (Canon) on Feb 11, 2005 at 21:49 UTC
    Pfft. Nasty.

    This is caused by looks_like_number(SV*), right?

    Does this constitute a bug, is it backward compatible behaviour, or should people just refrain from using _ as a NOP in numbers?

    J.

    update: OK, so it isn't a NOP, it's just syntactic sugar that doesn't do anything in a literal number, but you know what I mean..

      Does this constitute a bug ... ?

      I wouldn't call it a bug, unless I was also prepared to say these are:

      print 0+"0xFF"; # 0 print 0+"0755"; # 755 print 0+"0b11"; # 0

      But I don't think those are bugs, either.

      It's all pretty much defined behavior. Any language that makes thin distinctions between strings and numbers (as Perl does) needs to have some defined way of what strings do when they're applied to numbers, and what numbers do when applied to strings. You might take issue with the way Perl does that, and you might take issue with the fact that Perl doesn't have a value-based type system.

      But it's all well-defined and documented (more or less).

      "There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

        What I was getting at, is that in general perl promotes a number at the start of a string to the same number as if it was a literal. I was suggesting that since it doesn't in this case, you could consider it a bug.

        I do consider it a bug, but I would not consider changing the current behaviour before perl6, because of backward compatibility. It would break too subtly in too many scripts.

        As an example of "working" DWIM:

        my $i = 1234e3; my $j = "1234e3"; print join("\n",$i, $j, 0+$i, 0+$j);
      should people just refrain from using _ as a NOP in numbers?

      It's not that people should ... it's that people do refrain from using it that makes this nasty :-)

      (And the people who do use it ... only use it every third digit, and so we aren't used to looking at these wierd numbers with random _'s in them.)

      (Maybe this thread almost qualifies for the Obfu section...)

Re: Fun with Numbers
by Anonymous Monk on Feb 14, 2005 at 11:03 UTC
    Well, in the first line, you have a numeric literal. In numeric literals, one can use underscores to separate non-empty sets of digits. (Two underscores in a row, or a trailing underscore, gives a warning - a leading underscore means it's unparsable). The underscores are ignored.

    The second line has a string literal. It will be kept as is.

    The third line adds a number and a string. In that case, Perl numifies the string by calling atoi or atol. Which will stop parsing at the first underscore (a warning will be given). That's not a bug - that's just the way how it is.