Hello,

 I have a wish for Perl 6. I would like if the open-funktion
 opens only a file if it doesn't exist.
 Of course, I can first test if the file exist.

  if (-e $filename)
  { print "file already exists!"; }
  else
  { open (FH, ">$filename") }

 My suggestion is to have a character for the open-mode-character that
 indicate that the file should not already exist.

 For example:

  open (FH, "?>$filename") || die "can't open $filename: $!";  

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'm thinking of an operator that returns a "magical" FH working like the
ARGV one (with authomatic error handling etc. - obviously under Perl6
the beahviour could be tunable by means of modifiers, etc.), e.g.

  openmany my $fh, [list];
  while (<$fh>) {
    # ...
  }

Michele
--

Of course that should be "function".

{
   local @ARGV = qw(foo bar baz and some other files);
   while (<>) {
      # ...   ARGV and friends are at your disposal
   }

{
   temp $*ARGS = <<foo bar baz and some other files>>;
   while (<$ARGS>) {
      # ...
   }

However, there are *admittedly* rare cases in which it plainly won't do:

  while (<$fh>) { # $fh just as magic as ARGV
     my $l=<>;
     # ...
  }

And once one has such a function, then the default *ARGV beahviour may be
based upon it. Also, as I already said, in Perl6 users could be allowed
further degrees of customizability.

Michele
--

    my $fh = open 'foo.bar';
    for <$fh> {              # note, not while
        # do stuff
    }

While that probably works, I think better style would be to use a comma:

    my $fh = open ">$filename", :excl;

That explicitly passes :excl to open as a term in a list rather
than relying on the magical properties of :foo to find the preceding
operator adverbially when used where an operator is expected.  We may
have to tighten up the definition of operator :foo a bit, since it's
not always going to be clear which preceding operator is intended.
Even quotes are operators if you squint. Arguably, someone could look at

    my $fh = open ">$filename" :excl;

and legitimately wonder which predicate the :excl attaches to:

    my $fh = open (circumfix:""('>$filename', :excl));     # apply to quote
    my $fh = open(">$filename", :excl);                    # apply to open
    infix:=(my $fh, open(">$filename"), :excl);            # apply to assignment

I see several directions we could go to clarify this, and I don't
entirely like any of them.  One could look at the set of available
signatures (at either compile time or run time) and see who wants
that particular adverb.  But the early binding solutions tend to
bind too soon, and the late binding solutions tend to bind too late.
(The latter is much closer to how humans treat adverbs, though,
since humans are essentially MD creatures with an overlay of various
pre-compiled heuristics.)

Operator adverbs are, in essence, postfix operators with weird
precedence.  We're going to have to be very explicit about what we
mean by "weird" here.  Unfortunately, this morning I don't feel
very explicit.

  my $fh = open ">$filename", open::exclusive;

Is it reasonable to use package:: as a prefix to a block to change the
default namespace:

  { package open; exclusive + rw; }

becomes

  open::{exclusive + rw}

which then lets me say:

  my $fh = open ">$filename", open::{exclusive + rw};

=Austin

The problem with constants is that they're constant.  Sometimes you
don't want them to be:

    my $fh = open ">$filename", :encoding($myencoding);

: Is it reasonable to use package:: as a prefix to a block to change the
: default namespace:
:
:   { package open; exclusive + rw; }
:
: becomes
:
:   open::{exclusive + rw}

Except that syntax already means something else (lookup of a symbol
in the "open::" stash).

: which then lets me say:
:
:   my $fh = open ">$filename", open::{exclusive + rw};

If you want to call a function that will artificially multiplex several
arguments into a single argument, go ahead and call a function.
Functions are allowed to be package qualified, and they're allowed
to transmogrify random strings into package identifiers in whatever
package they like.  I don't think parameter names themselves need
to be package qualified though.  And I do think that something like
:excl is a boolean argument, not an object.  Explicitly making it
into an object (even so simple an object as a bit) seems to me like
a misfeature borrowed from C.

I can see how you're trying to use the identifier system to force
compile time checking of symbol names here, but that approach is going
to be of limited use in a language with MD.  Most parameter names will
end up being checked at runtime, and will end up throwing an exception
if no function with an appropriate signature can be found.  As I say,
you can always force checking with a function or macro of your own choosing:

    my $fh = open ">", $filename, *open::mode(:exclusive :rw);

But I think most people will prefer just to say

    my $fh = open ">", $filename, :exclusive :rw;

and take their lumps at run time.

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

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.

That is:

    my $fh = open 'foo.txt';
    $fh.print 'hello!';

Should be possible, as well as:

    my $fh = open 'foo.txt';
    print $fh.readline;

Modifiers could be used to force something into a separate mode. rw and
ro are used elsewhere in Perl 6 already, but obviously r without w would
also be handy.

    my $fh = open 'foo.txt', :ro;
    $fh.print 'hello!';  # Not possible

Of course, those who want the mode first can use

    my $fh = open :ro, 'foo.txt';

Which isn't too different from

    open my $fh, '<', 'foo.txt';

Or perhaps, for open an exception should be made, and r should be used
instead of ro.

    (open $outfile :append).print slurp $infile;

Or, for the shorthand junkies :)

    (append $outfile).print slurp $infile;

    while (IO::File->new($file)->readline) { ... }

either.

Of course, while-open is a good candidate for a warning.

I don't think this "problem" needs a solution. I hope or-cache will
still be an often used idiom in Perl 6:

    while <my $fh //= open $file> { ... }

Although I'm not sure what exactly "my" would mean here.

    open '<', $foo;
    open '>', $foo;

is much harder to read than

    open 'r', $foo;
    open 'w', $foo;

For the same reason, I prefer unified diff format to the </> format that
my copy uses by default.

    r       use
    w       clobber
    a       append
    rw      use

This can without too much trouble be solved with :append and :clobber.

However we have a precedent in m:i// where the :adverb comes directly
after the operator.  It's probably special because it "is parsed" that
way, but it's so common that I feel I can use it as a precedent anyway.

So if :adverbs are having such a weird time finding their verbs, wouldn't
it be easier to allow them to be placed directly after the verb all the
time?  Then the magic is merely moving it into the named args section
instead of wondering which operator's named args section it belongs to.

Then

  my $fh = open ">$filename" :excl;

is unambiguously

  my $fh = open (circumfix:""('>$filename', :excl));

while what was actually wanted is written as either of

  my $fh = open ">$filename", :excl;  # part of the arg list
  my $fh = open :excl ">$filename";   # adverb to open

And besides, I think it reads better when the adverb is next to the verb.

yes, no, maybe?

It's unambiguous becase a term is expected at that point, so :adverb
isn't really an adverb--it's just a pair constructor.

: However we have a precedent in m:i// where the :adverb comes directly
: after the operator.  It's probably special because it "is parsed" that
: way, but it's so common that I feel I can use it as a precedent anyway.
:
: So if :adverbs are having such a weird time finding their verbs, wouldn't
: it be easier to allow them to be placed directly after the verb all the
: time?  Then the magic is merely moving it into the named args section
: instead of wondering which operator's named args section it belongs to.
:
: Then
:
:   my $fh = open ">$filename" :excl;
:
: is unambiguously
:
:   my $fh = open (circumfix:""('>$filename', :excl));
:
: while what was actually wanted is written as either of
:
:   my $fh = open ">$filename", :excl;  # part of the arg list
:   my $fh = open :excl ">$filename";   # adverb to open
:
: And besides, I think it reads better when the adverb is next to the verb.
:
: yes, no, maybe?

Except that you've but :excl where the parse is expecting a term, so it
isn't an adverb.  It's just a pair constructor.  Which means that after
it the parser is expecting an operator, and blows up on the string literal.

The adverb notation as currently defined only works where an operator
is expected.  Which means it can't really be used on unary operators
unless there's some kind of pecking order where we try to apply it to
the unary operator, and if that fails, apply it to the preceding binary
operator.  But that's a headache waiting to happen.  I'm more inclined
to say that the adverb notation only works for binary operators, and
you have to use pair args with unaries.  So you can't write

    $x = rand 20 :bell_curve

because it would try to apply :bell_curve to the assignment, but you
can write

    $x = rand(20, :bell_curve)

I know it seems like the adverb syntax is misplacing the modifier with
respect to the binary operator it's modifying, but I think most of its
uses are actually very short:

    1..100:by(3)

If you really want something fancy, you'd be better off to write it
in functional form with a normal named pair argument:

    infix:..(1, <some_big_hairy_expression>, :by(3))

instead of

    1 .. <some_big_hairy_expression> :by(3)

Alternately, I do see an easy formatting hack:

    1 .. (<some_big_hairy_expression>)
      :by(3)

Just don't anyone suggest that we indicate what's modified
*syntactically* by placing the adverb directly under it...

Hmm.  Maybe with an extra uparrow?

    1 .. (<some_big_hairy_expression>)
      ^:by(3)

Yow.  Two-dimensional programs.  Reminds me of BF...

But we'd have to pay really close attention to how indenting is done.
Maybe we should just pass this suggestion on to Guido...  :-)

        open FH, "|/usr/bin/foo";

make a lot more sense. Using something like

        open "p", "/usr/bin/foo";

just wouldn't have the same ring to it. Aside from which, it gets even worse
when you consider how you would have to change:

        open FH, "/usr/bin/foo|";

0. More appealing to the eye
1. They do not ambiguate with files named 'r', or 'w'
2. They don't have to be translated (in german that would be 'l' and 's')
3. They play nice with possible extensions 'open ">:utf8", $file;

    open :r, $file;
    open :w, $file;
    open :rw, $file;
    open :r :w, $file;  # Hmm...

mijn $dbh = DBI->verbind(...);
mijn $sth = $dbh->bereid_voor($zoekopdracht);
$sth->voer_uit(@waardes);
$sth->bind_kolommen(\my ($foo, $bar));

zolang ($sth->apporteer) {  # :)
    toonf "%10s %d", $foo, $bar;
    volgende als $bar gd 15;

    open :w('utf8'), $file;

it would even make using different layers for in and output easy:

    open :r('iso-8859-15') :w('utf8'), $file;

although you shouldn't want that :)

    open :r :p, '/usr/bin/foo';  # Or :read :pipe
    open :rp, '/usr/bin/foo';    # IIRC, rules also let you combine
                                 # single-letter modifiers

And open2 is :r :w :p or :rwp or :read :write :pipe.

Or something like that.

  my $fh = open 'foo.txt', :w;
  $fh.say "Hello, world!";

  $fh = open 'foo.txt', :e;    # Ha, ha, just kidding!

  $fh.say <<<-EOF
    If wifey shuns
      Your fond embrace
    Don't kill the mailman:
      Feel your face!
    Burma Shave
  EOF

  $fh.close :q!;    # Tricked again.
  $fh = open :n;    # Opens next file from argv?

     $in=open :r "|/usr/bin/foo";
     $out=open :w "|/usr/bin/foo";
     $both=open :rw "|/usr/bin/foo";

The pipe would be legal on either side of the string.  This would still
allow the often-useful "type a pipe command at a prompt for a file",
while matching the trait-based syntax suggested elsewhere.

--
Brent "Dax" Royal-Gordon <br...@brentdax.com>
Perl and Parrot hacker

juerd@ouranos:~/tmp/example$ ls -R *
|:
usr

|/usr:
bin

|/usr/bin:
foo

Please let's not repeat this ...