On Wed, Mar 23, 2005 at 03:28:31PM +0000, Peter Haworth wrote:
: On Mon, 21 Mar 2005 08:41:27 -0800, Larry Wall wrote:
: > Okay, I've come around to liking it, but I think we have to say that
: > 0x, 0d, 0o, 0b, and whatever else we come up with are just setting
: > the default radix. If a string comes in with an explicit 0x, 0d, 0o,
: > or 0b, we believe that in preference to the operator.
:
: Don't we trust the programmer more than the data? I want this code to
: produce 4660, 22136, 2832, 3394; not 4660, 22136, 4, 42.
:
: for '1234','5678','0b10','0d42' {
: say 0x $_;
: }
Er, yes. Sorry--I forgot b and d were valid hex, sigh. Fortunately,
my extended brain caught it. :-)
But maybe that means that the 0b and 0d notations are bad, and we
shouldn't be trying to generalize the 0x pattern that way. We could
keep 0x for old times sake, but generalize it some other way. With all
the use we've made of my colon, we haven't actually used up :<digit>
yet, so we could go with
:16<feedfaceddeadbeef>
:8<4711>
:2<1000_0000>
:10<1_000_000>
:12<0123456789te>
Interestingly, that gives us a :16($x) operator for free.
Since the notation encompasses slices, it also gives us a method
of distinguishing exponents from mantissas for notations where "e"
is ambiguous:
:16<feedfaceddeadbeef 8>
About the only thing it doesn't give us is
:$radix<$input>
I suppose we could make Pairs interpret their right arg in numeric
context to let
$radix => $input
do the general thing, but that's getting a little out there.
Still, what other numeric interpretation might you want to give to a
pair object? The main problem with commandeering pair notation for
that is simply that it's not obvious, and for such a rare operation
you should use something huffmanly obvious. So we should probably
have a generalized radix_to_dec($radix,$input) function out there
somewhere instead.
But for literals and input values with a fixed radix, I kinda like
the : notation.
Larry
