enhanced open-funktion

[Unknown Sender]

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: $!";

Gerd

[Luke Palmer]

perl6-language-return-17800-fibonaci=babylonia.f...@perl.org writes:
> 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.

Like O_EXCL, yeah, that'd be nice.

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;

Luke

[Michele Dondi]

On Tue, 13 Jul 2004 perl6-language-return-17800-blazar=pcteor1.m...@perl.org wrote:

> 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.

I rather have a much "bigger" wish for an open-like operator that to be
fair I would like to see *also* in Perl5: nothing that one can do in well
more than one way in any case (also including creating a module that will
do exactly what I write below...), but that indeed would come handy
occasionally.

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
--
+++ wrote:
> Idiot.
top-poster
- Robin Chapman in sci.math,
"Re: This Week's Finds in Mathematical Physics (Week 204)"

[Michele Dondi]

On Tue, 13 Jul 2004, Michele Dondi wrote:

> I rather have a much "bigger" wish for an open-like operator that to be

^^^^^^^^

Of course that should be "function".

> I'm thinking of an operator that returns a "magical" FH working like the

^^^^^^^
[snip]
> openmany my $fh, [list];

And it should assign to an undefined scalar variable, rather than
returning the filehandle, for consistency with open().

Sorry,
Michele
--
comunque non ha le alette rosse.....e' metallo metallizzato colore
metallo....
- "Franz" su it.hobby.modellismo

[Jonathan Scott Duff]

On Tue, Jul 13, 2004 at 03:41:54PM +0200, Michele Dondi wrote:
> On Tue, 13 Jul 2004 perl6-language-return-17800-blazar=pcteor1.m...@perl.org wrote:
>
> > 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.
>
> I rather have a much "bigger" wish for an open-like operator that to be
> fair I would like to see *also* in Perl5: nothing that one can do in well
> more than one way in any case (also including creating a module that will
> do exactly what I write below...), but that indeed would come handy
> occasionally.
>
> 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>) {
> # ...
> }

From your description, it sounds like this is what you want:

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

I suppose the perl6 equivalent would be:

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

Not much different is it?

-Scott
--
Jonathan Scott Duff
du...@pobox.com

[Michele Dondi]

On Tue, 13 Jul 2004, Jonathan Scott Duff wrote:

> > I rather have a much "bigger" wish for an open-like operator that to be
> > fair I would like to see *also* in Perl5: nothing that one can do in well
> > more than one way in any case (also including creating a module that will

^^^^^^^^^^^^^^^^^
^^^^^^^^^^^^^^^^^

> > do exactly what I write below...), but that indeed would come handy
> > occasionally.

^^^^^^^^^^^^
^^^^^^^^^^^^

> From your description, it sounds like this is what you want:
>
> {
> local @ARGV = qw(foo bar baz and some other files);
> while (<>) {
> # ... ARGV and friends are at your disposal
> }
> }

Yes, in fact this is One Way To Do It(TM), and one that indeed I have
used, when I felt I needed it.

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
--
>> try sleeping on it, that usually works.
> I think you're right. Usually it works every time. ;-)
I don't know about that.
I tried sleeping on a big big problem and we're now divorsed.
- "Tralfaz" on sci.math, "Re: About a big big problem" (edited)

[Luke Palmer]

Michele Dondi writes:
> On Tue, 13 Jul 2004, Michele Dondi wrote:
>
> > I rather have a much "bigger" wish for an open-like operator that to be
> ^^^^^^^^
>
> Of course that should be "function".
>
> > I'm thinking of an operator that returns a "magical" FH working like the
> ^^^^^^^
> [snip]
> > openmany my $fh, [list];
>
> And it should assign to an undefined scalar variable, rather than
> returning the filehandle, for consistency with open().

How very convenient, because in Perl 6, open *does* return the file
handle. Valid Perl 6 code ahead:

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

Luke

[Larry Wall]

On Tue, Jul 13, 2004 at 07:24:55AM -0600, Luke Palmer wrote:
: 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;

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.

Larry

[Austin Hastings]

--- Larry Wall <la...@wall.org> wrote:
> 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.

Hmm. If I must use the comma, I think I'd prefer a constant in this
scenario:

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

=Austin

[Larry Wall]

On Tue, Jul 13, 2004 at 10:41:32AM -0700, Austin Hastings wrote:
: --- Larry Wall <la...@wall.org> wrote:
: > 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.
:
: Hmm. If I must use the comma, I think I'd prefer a constant in this
: scenario:
:
: my $fh = open ">$filename", open::exclusive;

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.

Larry

[Juerd]

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.

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

Juerd

[Larry Wall]

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

[Juerd]

Larry Wall skribis 2004-07-13 14:04 (-0700):

> 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. :-)

Well, open being much like IO::All::io would really make me happy.

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.

> my $fh = open $filename :excl;
> my $fh = append $filename :excl;
> my $fh = creat $filename :excl;
> ...er, I mean,
> my $fh = create $filename :excl;

That I would very much dislike. Let's not introduce keywords when the
same thing can be done by modifiers, unless something is used EXTREMELY
often (my mind has now accepted "say", but only because print "...\n" is
extremely common).

> Of course, append and create might just be shorthand for a normal open
> with a :create or :append arguments, I suppose.

I hope those keywords can be introduced with a pragma. "use
shorthands;". That pragma then does need a single letter command line
switch, because it would be very useful for one-liners.

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

I'd prefer

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

Or, for the shorthand junkies :)

(append $outfile).print slurp $infile;

> But that might be a little too concise for good error messages.

Assuming $infile ne $outfile and that the default error message (which
perhaps is only there if enabled with a Fatal.pm-like pragma) includes
the filename (it should, imo), two things being on one line shouldn't be
a problem.

> And they might lead people to write things like
> while <open $file> {...}

I've never seen

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.

> But :rw is more or less orthogonal to < and > in UnixThink.

There's one thing feel I must say about < and >: They're not different
enough, visually. This works well on the command line and for
delimiters, but

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.

> 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.

It's okay to have defaults, I think.

r use
w clobber
a append
rw use

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

Juerd

[John Williams]

On Tue, 13 Jul 2004, Larry Wall wrote:
> On Tue, Jul 13, 2004 at 07:24:55AM -0600, Luke Palmer wrote:
> : 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;
>
> 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.

[snip]

> I see several directions we could go to clarify this, and I don't

> entirely like any of them. [snip]

>
> 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 understanding is that the :adverb is at the end because it is passed as
a named argument, which must be after the positional arguments. And that
is certainly unambiguous with the comma.

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?

~ John Williams

[Larry Wall]

On Tue, Jul 13, 2004 at 03:44:11PM -0600, John Williams wrote:

: On Tue, 13 Jul 2004, Larry Wall wrote:
: > On Tue, Jul 13, 2004 at 07:24:55AM -0600, Luke Palmer wrote:
: > : 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;
: >
: > 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.
: [snip]
: > I see several directions we could go to clarify this, and I don't
: > entirely like any of them. [snip]
: >
: > 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 understanding is that the :adverb is at the end because it is passed as
: a named argument, which must be after the positional arguments. And that
: is certainly unambiguous with the comma.

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... :-)

Larry

[Michele Dondi]

On Tue, 13 Jul 2004, Juerd wrote:

> open '<', $foo;
> open '>', $foo;
>
> is much harder to read than
>
> open 'r', $foo;
> open 'w', $foo;

Are you sure?!? I would tend to disagree... not that MHO is particularly
important, I guess, but just to stress the fact that it is by large a
subjective matter...

Michele
--
Oh, for God's sake! Earnest misunderstanding I can cope with,
stupidity I can cope with, complete lack of sense of humour I can cope
with, but lying I cannot.
*PLONK*
- Ben Morrow in clpmisc (slightly edited)

[Greg Boug]

On Thursday 15 July 2004 19:42, Michele Dondi wrote:
> > open '<', $foo;
> > open '>', $foo;
> >
> > is much harder to read than
> >
> > open 'r', $foo;
> > open 'w', $foo;
> Are you sure?!? I would tend to disagree... not that MHO is particularly
> important, I guess, but just to stress the fact that it is by large a
> subjective matter...

I have always felt that keeping it the same as shell scripting was a handy
thing, especially when I have been teaching it to others. It also makes
the ol' perl5

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|";

Greg
--
Greg Boug (gb...@unico.com.au)
Systems and Network Administrator
UNICO Computer Systems
Melbourne, Australia.
Phone: +61-3-9865-9116

[H.Merijn Brand]

On Thu 15 Jul 2004 11:42, Michele Dondi <bla...@pcteor1.mi.infn.it> wrote:
> On Tue, 13 Jul 2004, Juerd wrote:
>
> > open '<', $foo;
> > open '>', $foo;
> >
> > is much harder to read than
> >
> > open 'r', $foo;
> > open 'w', $foo;
>
> Are you sure?!? I would tend to disagree...

So do I. "<", and ">" are imho MUCH clearer than 'r' and 'w' for several
reasons

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;

> not that MHO is particularly
> important, I guess, but just to stress the fact that it is by large a
> subjective matter...

--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.8.3, & 5.9.x, and 809 on HP-UX 10.20 & 11.00, 11i,
AIX 4.3, SuSE 9.0, and Win2k. http://www.cmve.net/~merijn/
http://archives.develooper.com/daily...@perl.org/ per...@perl.org
send smoke reports to: smokers...@perl.org, QA: http://qa.perl.org

[Juerd]

H.Merijn Brand skribis 2004-07-15 11:57 (+0200):

> 1. They do not ambiguate with files named 'r', or 'w'

Not a problem, assuming that these are named arguments as in:

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

> 2. They don't have to be translated (in german that would be 'l' and 's')

zeg "hallo, wereld";

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;
}

No, translations don't work in programming.

> 3. They play nice with possible extensions 'open ">:utf8", $file;

But

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 :)

Juerd

[Juerd]

Greg Boug skribis 2004-07-15 20:01 (+1000):
> open FH, "|/usr/bin/foo";

I'd love to be rid of -| and |-. I always have to RTFM to know which
one is which.

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

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

open :w :p, ...;

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

Or something like that.

Juerd

[Smylers]

Greg Boug writes:

> I have always felt that keeping ['>' and '<'] the same as shell
> scripting was a handy thing, ...

Using C<:w> and C<:r> would at least match what C<:w> and C<:r> do in
'Vi' ...

Smylers

[Austin Hastings]

--- Smylers <Smy...@stripey.com> wrote:
> Using C<:w> and C<:r> would at least match what C<:w> and C<:r> do in
> 'Vi' ...

That seems intuitive:

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?

=Austin

[Brent 'Dax' Royal-Gordon]

Greg Boug wrote:
> I have always felt that keeping it the same as shell scripting was a handy
> thing, especially when I have been teaching it to others. It also makes
> the ol' perl5
>
> 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|";

My personal preference is for:

$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

Oceania has always been at war with Eastasia.

[Juerd]

Brent 'Dax' Royal-Gordon skribis 2004-07-15 13:04 (-0700):

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

No, thank you. Please let us not repeat the mistake of putting mode and filename/path in one argument.

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

|/usr:
bin

|/usr/bin:
foo

Juerd

[Smylers]

Brent 'Dax' Royal-Gordon writes:

> My personal preference is for:
>
> $in=open :r "|/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",

And it still allows for all those security holes in websites where
inexperienced programmers are just expecting a filename but write code
that's capable of executing commands. Such behaviour is non-obvious to
somebody who hasn't been specifically warned about the danger, and the
potential for abuse is high.

Please let's not repeat this ...

Smylers

[Jonadab The Unsightly One]

Luke Palmer <lu...@luqui.org> writes:

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

Can we please not name it with a random character generator? How
about something that communicates what it does in some fashion, at
least well enough to function as a mnemonic?

my $fh = open $filename :rw :noreplace;

If :noreplace is too lengthy, how about :create or :new or :safe or
something?

--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}}
split//,"ten.thgirb\@badanoj$/ --";$\=$ ;-> ();print$/

[Jonadab The Unsightly One]

Larry Wall <la...@wall.org> writes:

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

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

Yes, please leave column-alignment tricks to Python. I don't even
like the fact that indentation is significant in POD, to the extent
that I've given up on the idea of putting the documentation with the
code in Perl5 (the whole point of POD, so I thought), because of the
havoc it wreaks on the indentation.

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

seems fine to me. The parens should keep the adverb from applying to
anything inside of them, and so assuming that the parens themselves
don't take adverbs[1], then the adverb applies to the preceding
operator, in this case the range operator.

I think that should be the rule: the adverb should apply to the
closest preceding thing that can take adverbs. That's a simple rule,
and it's _approximately_ similar to how it works in English, most of
the time (except that in English we also allow the adverb to come
before the thing it modifies, or in some cases to modify the entire
clause, and a few other complications not worth going into ATM).

So, then, with something like

open "$( $file ).log" :follow;

We have to decide whether quotes are allowed to take adverbs; if they
are, then that has to be written differently:

open ($file . ".log") :follow;

Which in some ways looks cleaner anyway.

(As far as :follow goes, I'm imagining something like tail -f does,
but I'm currently not prepared to argue for the inclusion of such a
feature; it's just an example of an adverb.)

OTOH, do quotes constructs really need to be able to take adverbs? A
negative answer allows the parens above to go away, and it seems like
it would play okay with most things. Certainly, in the case of
pattern matching, it is not the quoting character that takes the
adverb:

m :i /foo/

The adverb attaches to the m (or the s or whatever). And if we're
still to have qq and its kin, they could take adverbs in the same
fashion, presumbaly:

qw :pairs (a A b B c C);
qq :xyzzy "Some Arbitrary String";
q :plugh {Another String};

It seems to me that thus it is not strictly necessary for regular
quotes to be able to take adverbs directly, since qq and so on can.
(We'd probably be losing the ability to use colon as the quoting
character. To me, that seems better than having "Some String" :adverb
attach the adverb to the quote marks. Maybe I'm just odd.)

Someone will doubtless point out that quotes are just a special kind
of circumfix operator. Do circumfix operators need adverbs, though?
I'm *really* hoping that parentheses don't need them[2]. Aren't those
theoretically just circumfix operators too (if you squint)?

Larry suggested that maybe only binary operators need adverbs. I'm
not sure about that. But I'm leaning toward thinking that circumfix
operators, at least, don't need them.

---
Footnotes:

[1] No. Just say no.
[2] ibid.

[Jonadab The Unsightly One]

Juerd <ju...@convolution.nl> writes:

> Not a problem, assuming that these are named arguments as in:
>
> open :r, $file;
> open :w, $file;
> open :rw, $file;
> open :r :w, $file; # Hmm...

I like this approach. :a seems a probable replacement for ">>$file"
then; one imagines that :a would be mutually exclusive with certain
other options.

> No, translations don't work in programming.

They can, at least in theory, but it's a separate issue, one that need
not concern us here at present. And if you did l6e the programming
language itself, the changes would be more complex than merely
substituting a few keywords; depending on locale you'd want to have
inflected keywords -- and if the notion of having those in Perl
doesn't set your brain to hurting, just think about combining them
with continuations inside of a self-modifying string eval.