Larry Wall wrote:
On Thu, Mar 17, 2005 at 10:31:07PM -0600, Rod Adams wrote:I'll try to come up with something decent, if no one beats me to it.
: Aaron Sherman wrote:
: >>Methods on numeric values (should be defined as pseudo-methods on
: >>unboxed numbers):
: >>
: >> chr
: >> hex
: >>oct
: >> : >>
: >
: >Sigh... well, now I know what Ctrl-Return does in Evolution :-/
: >
: >Ok, so what I was getting at was that the above three are methods on
: >numbers.
: >
: True, but they are not math functions. They are Num <--> Str : conversions, and I haven't figured out where to put those yet.
oct and hex are arguably misnamed, since most functions are named by
what they produce, not by what they take as input. I don't know what
the replacement should be, though. Maybe it's not worth fixing.
Sadly, the C style hex2int, oct2int might be the least confusing, but heinously ugly.
: >>vec
: >> : >>
: >
: >This is pack with issues :)
: > : >
: If nothing else, I plan on making a form that works on Int as well as : one that works on Str. I don't know how many times I've had to resort to : masks and shifts to do something vec should have done for me nicely.
I would love to kill vec in favor of declared arrays of tiny
integers, which could presumably be mapped onto other data types
like bytesstrings or integers. This is one of those areas where we
can make good use of the notion that a variable is a view onto some
other piece of data that may not even know it's being viewed strangely.
Could some form of C<:=> do this?
my uint4 @nibbles; my str $ascii;
@nibbles := $ascii;
$ascii = 'Perl Hacker'; say @nibbles[4];
Would probably need some other bind operator, for the sake of type checking. Maybe resurrect the C/C++ union construct. hmm. I don't know.
But I think we can keep C<vec>, even spruce it up a little, and then neglect to import it into *:: if we find something better.
-- Rod Adams
