On Tue, Jul 13, 2004 at 09:25:52PM +0200, Juerd wrote:
: Luke Palmer skribis 2004-07-13  7:24 (-0600):
: > But in Perl 6, you don't have to specify things like that through the
: > mode string: you can specify them through named parameters:
: >     my $fh = open ">$filename" :excl;
: 
: I was hoping we could finally get rid of mode characters, and especially
: combined mode and filename in one argument.

The combined form is definitely problematic in various ways, and we haven't
really redesigned open yet, since we haven't got to A29 yet.  :-)

We could mandate the two argument form.  Or we could decide that "open"
is one of those overly general concepts, and separate things by name:

     my $fh = open $filename :excl;
     my $fh = append $filename :excl;
     my $fh = creat $filename :excl;

...er, I mean,

     my $fh = create $filename :excl;

Of course, append and create might just be shorthand for a normal open
with a :create or :append arguments, I suppose.  Similar considerations
apply for piped commands, though what the appropriate words might be,
I don't know offhand.

Another interesting question is how well those things read in code like this: 

    @lines = <open $infile>;
    print (append $outfile): @lines;

Or equivalently:

    <open $infile> ==>
    print (append $outfile):

But that might be a little too concise for good error messages.  And they
might lead people to write things like

    while <open $file> {...}

which wouldn't necessarily work.  At first blush, I'd expect that
to reopen $file every time through the loop, which is probably not
what the user expects.  Possibly <...> in scalar context is smart
enough to cache its iterator, but then you start getting into the
"return false once" syndrome that confuses people.  The inside of
<...> isn't really a closure.  So maybe <...> is smart about closures:

    while <{open $file}> {...}

and only calls its closure after its previous iterator is exhausted.
On the other hand, iterators tend to *look* like closures anyway,
so may that'll be hard to distinguish in the absence of a declared
return type.

But I digress...

: Ever since I read about the new :pairs, I thought that would imply :rw
: instead of >.

But :rw is more or less orthogonal to < and > in UnixThink.  The fact
that you want to both read and write a file says nothing about whether
you initially want to use, clobber, or append to an existing file.

Larry

Reply via email to