Larry Wall writes:
> Synopsis 2: Bits and Pieces
Nice. (Minor pod corrections sent as a diff under separate cover.)
> 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.
> To get a Perlish representation of any data value, use the C<.repr>
> method. This will put quotes around strings, square brackets around
> list values, curlies around hash values, etc., such that standard Perl
> could reparse the result. XXX .repr is what Python calls it, I think.
> Is there a better name?
Yes; I've no suggestions as to what it might be, but surely there's
_got_ to be a better name than C<.repr>.
> 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!
> 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).
> A bare closure also interpolates in double-quotish context. It may
> not be followed by any dereferencers, since you can always put them
> inside the closure. ... The old disambiguation syntax ... is dead.
> Use closure curlies instead:
>
> {$foo[$bar]}
> {$foo}[$bar]
That last example seems to violate the previous stipulation about not
following a closure by dereferencers.
> 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.
> and steal the angles for something else.
If past performance is anything to go by, the main victim of freeing the
pointies for another purpose would be Piers -- threads on this mailing
list of people "discussing" operator syntax have a habit of getting
quickly out of control.
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.
Thank you again for coming up with this!
Smylers
