On Sat, Dec 04, 2004 at 11:02:38PM +0300, Alexey Trofimenko wrote:
: hm. we have short and strange <FH>, for input.. (and for some reason, it
: is bracketing! there's no sense at all in it)
: ..but we have long (and even looking slightly OOish, in perl5 sense) print
: FH for output, and noone complained. We still aint going to have funny
: syntax for output, and we not going to keep old syntax for input. Why to
: reintroduce even more strangeness with that unary =, which is actually a
: simple list operator, which doesn't desire for huffmanizing?
True, except for the fact that it *is* unary rather than list, so it
doesn't require parens to interpolate =$fh into a list. I had been
thinking that there should be a long form as well, just as we have
both !/not, and ?/true.
: I don't think that would hurt anyone
: for lines <file1 file2 file3> {...}
: # or
: for files <file1 file2 file3> {...}
: # or
: for lines @*ARGS {...}
: # or just that special case:
:
: for lines {...}
But that last one is the one that *doesn't* work if lines is a list operator.
List operators always expect a term, and {...} is recognized as a statement
block only where an operator is expected.
It would be parsed as:
for lines({...}) ???
: but actually everybody just miss that short and strange
: while (<>) {...}
: and how all other handles would be accessed is much less concern.
: it's just a bad and beloved habit, IMHO.
Definitely beloved. Bad? I dunno. It's definitely visually distinct,
and that's why I put it into Perl that way in the first place. The data
flow of your program is only partially related to the control flow,
and something that is producing asynchronous data needs to stand out.
: maybe we could make a special case.. (C programmers would be shocked)
: for () {...}
I think that should just do nothing, so that a code generator can spit it
out without worrying about the special case. I still think the special
case is either of
for =<> {...}
or
for lines <> {...}
at the writer's discretion.
But I do like your lines/files distinction, which = doesn't make. Probably
if we distinguish them as list operators, we make the unary = only do
lines. Then in scalar context it just gives you the next line, which
will be more familiar to people coming from <FH> think.
I suppose we could also have
for words <> {...}
for tokens <> {...}
for paragraphs <> {...}
for chunks(<>, :delim(/^^===+\h*\n/)) {...}
etc.
On the other hand, if we follow the Perl 5 model, maybe = always
means chunks, and the filehandle just defaults to chunking into lines
like Perl 5's <> in the absence of a $/ redefinition. Presumably
words/tokens/lines/paragraphs/files would just synonyms for chunks in
that case. And maybe records/rows for people who don't like chunks. :-)
But I think people would expect something like "words" to override
the filehandle's natural chunking proclivities at least temporarily
in the case of a scalar input. So I think =$fh means chunks($fh),
the natural chunking of the filehandle (defaulting to lines), while
the words/files/paragraphs do temporary override of chunking policy.
Presumably there are also :words, :files, and :paragraphs adverbs on
the opening of the filehandle to set the default chunking. No reason
to make them different words. Or maybe they're all args to a single
:by<words> adverb. And perhaps that also turns on autochomping.
Larry
