Nathan Wiger writes:
: First off, before I forget to mention it, nice job on Apoc2 Larry! You are
: the man. I know alot of us on p6l can seem like harsh critics at times, but
: it's only because we love Perl so much. ;-)
We'll have to do something about that. :-)
: Anyways, in addition to the $file.next stuff, I'm curious about a few
: clarifications on the new semantics of arrays and hashes. Overall it looks
: outstanding. I'm interested in what happens with interactions:
:
: $a = @b;
:
: Does this:
:
: 1. Get the length (doesn't seem to make sense now)
: 2. Pull a reference to @b (like Perl5's "$a = \@b")
: 3. Get the first element of @b
Scalar context always gets the reference, even for &func in the
absence of parens.
: Similarly, how about:
:
: %c = @d;
:
: Does this:
:
: 1. Create a hash w/ alternating keys/vals like Perl5
: 2. Do the equivalent of "%c = \@d" in Perl5
: 3. Or the mystery meat behind Door #3
I expect it's mystery meat. #1 is probably done by some equivalent to:
%c = pairify @d;
The bare assignment probably provides hashlist context to the right
side, which treats => elements as pairs, and other elements as keys for
which a default value should be assumed. That default value is likely
a property of target hash object (or perhaps of the %c variable object,
which is not quite the same thing).
: Also, I like the *@b prototype slurping idea a lot, but I do worry about
: potential confusion with the @*b special class notation. I'm wondering if
: the latter can't be @::b?
I wanted to keep true globals out of Main (presuming for the sake of
argument that the bare :: still indicates the user's main package).
Mostly @*FOO is just a shorter way to say @CORE::FOO. The actual
character is negotiable. I've considered using $:FOO with one colon,
but held off on that under the assumption that $: might be a unary
typecast meaning scalar(). But there's something to be said for
using $=, @=, %=, for unary typecasts, so that would free up : to
use in $:STDIN and such.
In any event, I'm not too worried about confusion between *@foo and @*foo,
since people will usually use the @foo form anyway for the global. Leaving
people confusion out of it, the computer won't get confused unless people
start trying to call global subroutines without a leading &:
@lines = *glob(...)
But I think we'd have just about as much problem with almost any other
character we pick. It's still possible we could preserve : sufficiently
to allow its use as a unary, so that
@lines = :glob(...)
would unambiguously mean core glob(). But probably not, given how many
things want a piece of : yet, even after giving properties the heave ho
on that score. So my thinking was, let's leave it as $*STDIN for the
moment, and consider it a placeholder for something that might or might
not become obvious at a later time. Meanwhile, we know we can always
write &*glob() in the rare cases we really need to.
Larry
