Re: RFC 51 (v2) Angle brackets should accept filenames a

Chaim Frenkel wrote:
> >>>>> "JE" == Jon Ericson <[email protected]> writes:
> JE> $gaz contains the second line.  Otherwise this:
> 
> JE>   while (<'filename'>){print;};
> 
> JE> won't work.  This gets a little hairy, I admit.
> 
> Actually they are two different problems. The while loop can be
> internally replaced with an open, while, close. Or with a local
> version of a filehandle that _only_ is valid at that line or
> block.

Sometimes I do this:

  <'somefile'>; # I don't care about the first line
  while (<'somefile'>){
    # do something with the rest of the lines
  };

> The same string being the same file is more of an issue. Just
> consider having two different modules/packages, opening the same
> file. You _might_ want them to have different meanings.

Good point.  Filehandles opened for string constants should tightly
scoped.  (Filehandles opened for scalar variables should have the same
scope as the variable.)  I still need to think about this (and get more
advice).

> JE> To my eye angle brackets signify input.
> 
> Perhaps but what about Damien's proposal
> 
>         if ($x < foo() > $y) { ... }
> 
> Remember perl has to intuit among,  < file >, <, <= , !<, etc.
> 
> I'd rather not add to the load.

perlop/"Gory details of parsing quoted constructs" has some detailed
discusion about how this sort of thing is parsed now.  The input
operator will fill the <file*glob> niche.  Perhaps there should be a
qi<> or i<> quote mechanism as well so that alternate delimiters could
be used.

> However, there is the concept of lazy evaluation that has been
> proposed so you might be able to get your way.
> 
>         @foo = lazy grep ....
>         while( <@foo> ) { ... }
> 
> However, I'd rather you limit your proposal to being valid only at a
> single spot in the code.  Similar to the .., and ... toggle
> operators. So that different usages of the same string mean different
> filehandles.

What does lazy grep do?  How does this apply?

> I'm not quite in favor of the proposal, since DWIMing the meaning of
> a string doesn't seem to be clear. Perhaps you should go through all
> of the possiblities.
> 
> You will also have to consider, if the string is to be put through
> magic open? or strictly valid file and directory names. What about
> the proposed URL intuiting? Should that be accepted?

Yep.  I hope to put it in v3.

  print <'http://dev.perl.org/rfc/51.pod'>;

Jon
-- 
Knowledge is that which remains when what is
learned is forgotten. - Mr. King