On Sat, Aug 14, 2004 at 09:56:34PM +0000, Smylers wrote:
: > You may interpolate a package name into an identifier using
: > C<::($expr)> where you'd ordinarily put the package name. The parens
: > are required.
: >
: > XXX Actually, C<::{$expr}> might be made to work instead, given that
: > that's how you treat a package symbol table as a hash, and inner
: > packages are stored in their parent hash. And curlies would be more
: > consistent with closure interpolation in strings. We'd just need to
: > make sure C<$::{$foo}::bar> parses correctly as a single name token.
:
: Using braces seems more intuitive, and hence easier to remember.
Okay, that section now reads:
You may interpolate a string into a package or variable name using
C<::{$expr}> where you'd ordinarily put a package or variable name.
The string is allowed to contain additional instances of C<::>, which
will be interpreted as package nesting. You may only interpolate
entire names, since the construct starts with C<::>, and either ends
immediately or is continued with another C<::> outside the curlies.
All symbolic references are done with this notation:
$foo = "Foo";
$foobar = "Foo::Bar";
$::{$foo} # package-scoped $Foo
$::{"MY::$foo"} # lexically-scoped $Foo
$::{"*::$foo"} # global $Foo
$::{$foobar} # $Foo::Bar
$::{$foobar}::baz # $Foo::Bar::baz
$::{$foo}::Bar::baz # $Foo::Bar::baz
$::{$foobar}baz # ILLEGAL at compile time (no operator baz)
${$foobar}::baz # ILLEGAL at run time (no hard ref in $foobar)
Note that unlike in Perl 5, initial C<::> doesn't imply global.
Package names are searched for from inner lexical scopes to outer,
then from inner packages to outer. The global namespace is the last
place it looks. You must use the C<*> package to force the search
to start in the global namespace.
: > To get a formatted representation of any scalar data value, use the
: > C<.as('%03d')> method to do an implicit sprintf on the value. To
: > format an array value separated by commas, supply a second argument:
: > C<.as('%03d', ', ')>. To format a hash value or list of pairs,
: > include formats for both key and value in the first string: C<<
: > .as('%s: %s', "\n") >>.
:
: Yay -- that sounds very useful!
The main problem with it is that there's no way to write the default behavior.
: > As with Perl 5 array interpolation, the elements are separated by a
: > space. (Except that a space is not added if the element already ends
: > in some kind of whitespace.
:
: I like that exception; it means that if all your array elements end with
: line-breaks, you don't end up with all but the first one being indented
: (which confused me lots when I was just starting out with Perl, and I've
: seen many others do it since).
That's the default behavior you can't write with .as(). Takes a .map or
some such.
: > XXX We could yet replace <$foo> with $foo.more or $foo.iter or
: > $foo.shift or some such (but not $foo.next or $foo.readline),
:
: That sounds good to me -- C<< while (<$file>) >> is one of the
: least-intuitive bits of syntax to get across to people learning Perl;
: there doesn't seem to be reason why this particular method call should
: get a purely symbol name, especially when something much more common
: such as C<print> doesn't.
:
: Something lie C<.iter> isn't much more to type, and it doesn't involve
: pressing Shift (or possibly something even more exotic on international
: keyboards) to type the pointies.
But .iter is ugly, ugly, ugly. Worse the .repr in my opinion.
Unfortunately, most of the the good names are taken, like "all",
"each". That's why we've tended to end up back with <$IN>.
: > and steal the angles for something else.
:
: For what it's worth, I'd be happy to use ordinary pointies instead of
: the guillemets for quoting words (and hash keys and the like), leaving
: the guillemets just for hyper ops. I still think your original analysis
: that word-quoting is more common than file-iterating is correct, that
: both of them are more common than hyper ops, and that there's some
: advantage to having the more complicated-looking (and -to-type)
: characters only being used for the more complicated operators.
The problem with that is that, both visually and conceptually, it's
more ambiguous with the infix:< operator. You'd get people writing
things like $foo<2 and wondering why it blows up. $foo«2» is much
more visually distinctive, and I think visual distinctions trump
ease of typing.
I'm actually wondering whether we should leave <...> free for
user-defined quoting purposes. Actually, we could leave <...>
defaulting to meaning .iter (or whatever), but if the user overrode the
meaning of <...>, they'd just have to use the method instead of <...>.
One is almost tempted to say that iterators should be declared as
self-growing arrays, but then you get problems with the fact that
@*IN in list context would not, in fact, read the array destructively,
which it needs to do.
One is also tempted to play with syntax like:
for *$*IN # ick
for $*IN[] # doesn't imply destruction of @$*IN
for $*IN... # a little weird, but maybe workable
If one goes with a standard method name, we also want to see what it
looks like as an indirect object:
for more $*IN
for iter $*IN
for every $*IN
for read $*IN
for in $*IN
for shift $*IN
Like I say, all the good ones are taken:
for all $*IN # all() is junction
for each $*IN # each method wants closure if we follow Ruby
for next $*IN # next $foo is a loop exit
Hmm. Maybe the problem is that we shouldn't follow Ruby on .each's
signature. How about we have .apply or .filter do the Ruby implicit
iteration thing, and keep .each for iterating iterators.
Hmm.
@bar = filter @foo: { $_ * 2 };
@bar = @foo.filter:{ $_ * 2 };
@bar = @foo.filter({ $_ * 2 });
filter @foo: { $_ * 2 } ==> @bar;
We could try to force .map into that role, except that the indirect
object version of map would look like
map @foo: {...}
which is backward from what people expect of map. Filtering is
probably a more accessible concept anyway.
Larry
