Smylers writes:
> > ... It's almost getting to the point where we want to allow
> > disambiguating underscores in operators: >>_+<_<<. Alternately we
> > give up on <<>> as a qw// replacement and allow spaces: >> +< <<.
>
> How about going back to what you originally decreed in Apocalypse 2,
> that the replacement for:
>
> qw<Statler Waldorf>
>
> will simply be:
>
> <Statler Waldorf>
>
> I think your reasoning, that using up a perfectly good set of brackets
> for input is a waste, still stands. It's also among the things people
> new to Perl find the most confusing, compared to an explicitly named
> function or method that they might expect for input; I don't think
> there'd be the same problem with something called C<read> or C<get> or
> C<getline> or C<input> or C<from> or C<line> or C<chunk> or C<data>.
I feel uneasy about that. <foo> is not just input, it's iteration. You
say <$iter> to grab the next element of the iterator (or all remaining
elements in list context). Using C<read> for that would be more than a
little awkward.
> You describe as "likely" that in common situations no operator or
> function name will be needed anyway -- do you still think that's the
> case?
>
> (I also note that if people are really attached to the special case of
> empty C<< <> >> meaning 'read from files named in C<@ARG> or from stdin
> if C<@ARG> is empty', that could be left in, since it doesn't at all
> conflict with putting something inside the pointies to quote them. But
> I'm still not keen on that.)
>
> Or how about using backticks for quoting words:
>
> my @person = `Statler Waldorf`;
>
> Running shell commands and retrieving their output is also fairly rare,
> and doesn't really need special quote-symbol-using operator --
> especially when compared to the C<system> command, which manages to do
> something quite similar as a mere named function. (Having them both as
> named functions might also reduce the incidences of people grabbing the
> command's output when they didn't mean to.)
Hmm. Although I love the visual appeal of << quote words >>, this would
be pretty nice for keeping from overloading << >> too much. And then
spaces would be allowed around hyper operators, which is a huge plus.
I'm starting to reconsider my position on Larry's proposal, though. The
one-sided hyper operators are nice, but they don't buy us anything
semantically (being disambiguatable with a unary + most of the time).
And while they "feel good" syntactically, they seem to complicate
matters -- matters most everyone was liking -- into oblivion.
It's also something to note that for a language which allows you to make
your own operators, it has an extremely brittle syntax. I don't think
any of us want what "fixing" that will do.
> > But we also have the ambiguity with <<'' and friends, so maybe the
> > real problem is trying to make the << and >> workarounds look too much
> > like  and Â. Maybe they should be :<< and :>> or some such. Maybe
> > we should be thinking about a more general trigraph (shudder) policy.
>
> If you go along those lines then implementing (some of) those in RFC1345
> would at least avoid inventing yet another set of symbols. They are
> reasonably mnemonic ("<<" does indeed stand for "Â"), so you'd only need
> to pick designate the colon (or backtick or whatever) as the
> digraph-designator and what follows is anything in that RFC.
>
> That also has the advantage that 'Vim' users only need to learn one set
> of mappings from digraphs to non-Ascii characters, thereby providing a
> memorable upgrade path: people without the appropriate symbols have to
> learn to type things such as these in Perl:
>
> :<<
> :*X
> :.M
>
> if they upgrade their terminal/fonts/whatever then they can now insert
> the actual characters, and they can use the digraphs they've already
> learnt, simply pressing Ctrl+K instead of colon:
>
> Ctrl+K << Â
> Ctrl+K *X Ã
> Ctrl+K .M Â
>
> I of course realize that not everybody uses 'Vim', but it is an RFC, and
> possibly in use elsewhere too.
Everyone who counts uses vim :-)
Luke
