"Michael Lazzaro" <[EMAIL PROTECTED]> wrote:
> OK, back to this, so we can finish it up: we have a number of proposals
> & questions re: string-to-num conversions, and from Luke we have some
> initial docs for them that need completing.  Can I get more feedback on
> these issues, plz, and any other String -> Number proposals/questions?
>
>
> (A) Unification of Literal <--> Stringified Numeric Behaviors

I vote yes

> (B) We want to be able to convert strings to numbers, using strings in
> any of the formats that literals understand.  If (A) is accepted, this
> is unnecessary:

Actually, even with A, I think its good to have it explicit. It gives us a
name to hook pragmas and ajectives onto [see (E), below].

> (C) We sometimes want to be able to specify the _exact_ format a string
> should be expected as.  Suppose you wanted a user to always enter a hex
> value: they should be able to just enter "10" or "ff", and you wanted
> to convert that to 16 and 255, respectively.  So you'd maybe use
> something like:
>
>      my $s = "ff";        # note there's no '0x' in front
>
>      my int $i = hex $s;
>      my int $i = $s.hex;

Yes to both these

>      my int $i = $s.numeric('%2x');  # ???

This doesn't seem to buy anythings really. I'd prefer:

  my $i = $s.sscanf('%2x').

Than all formats can be used: not just those that return numbers.

> (D) There were proposals to allow a given string to _always_ be
> numified in a certain way by attaching a property, e.g.:
>
>      my str $s is formatted('%2x');
>      $s = 'ff';
>      my int $i = $s;  # 255

My initial reaction is to X it. If someone could demonstrate a real-world
example where it helps (and is better than a regex based solution), I might
reconsider.

> ....now I'm wondering if that's buying us anything, though the inverse
> seems much more useful:
>
>      my int $i is formatted('%4x');
>      $i = 255;
>      print $i;    # prints '00ff';

I can see where it might help. Though perhaps a runtime property might be
more useful. Personally though, I'd axe it for now. Perhaps someone can
write the module in a few years time.

> (E) We need to finalize what happens when a string isn't a number, or
> has additional trailing stuff.  Damian gave his initial preference, but
> we need to verify & set in stone:
>
>      my int $i =  'foo';   # 0, NaN, undef, or exception?
>      my int $i = '5foo';   # 5, NaN, undef, or exception?
>
>      my Int $i =  'foo';   # 'Int' probably makes a difference
>      my Int $i = '5foo';

This is probably a case where "it depends". It would be good to have a
predicate that checks a string for its numberness:

  my $x = "5foo";
  fail unless is_number($x);

Going further, if the C<literal>/C<number> [see (B), above] is a named
function, then we can have a pragma:

  use fail 'literal';

which defines the rules for the current lexical scope. The default behavior
can depend on the warning/strictness pragmas currently in force:

  use strict 'literals';
  use warnings 'literals';

should be available.


Dave.


Reply via email to