enhanced open-funktion
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
Re: scalar subscripting
On Fri, Jul 09, 2004 at 05:02:48PM +0100, Jonathan Worthington wrote:
> > >Are there plans in Perl 6 for string modifiers?
> > Not exactly. But method calls can be interpolated into strings, so most
> > > As they are in bash eg.:
> > > ${var%glob_or_regexp}
> > > ${var%%glob_or_regexp}
> >
> > my $newfile = "$str.subst(rx|\.\w+$|, '')\.bin";
But what about the value of $str after interpolation?
In shall it stays it's original value! I would often need,
to use a little modified value of $str for a particular expression.
I like the way shell does it, to be able to write it such short,
without any other explicit variable.
Best regards
Hans
--
Why PHP? See man HTML::Embperl from libhtml-embperl-perl.deb!
http://perl.apache.org/embperl/
regexp abbreviations matching
Hello, I am missing, in Perl5, some shortcut for matching not whole word, e.g.: /^--v(?:e(?:r(?:s(?:i(?:on?)?)?)?)?)?$/ Would there be something in Perl6? For Perl5 I suggest somenthing like this /--v(?-ersion)$/ Best regards Hans -- Faight against terrorism? What about terrorism by sw. patents? http://www.ffii.org/
Re: scalar subscripting
> > > my $newfile = "$str.subst(rx|\.\w+$|, '')\.bin"; > >But what about the value of $str after interpolation? > In shall it stays it's original value! I would often need, > to use a little modified value of $str for a particular expression. > I like the way shell does it, to be able to write it such short, > without any other explicit variable. Yeah, the fact that substitutions were only destructive in Perl 5 was a major kludge. I was taking the .subst method there as a functional, non modifying version. So: $str.subst(...) # returns substituted string, leaves $str alone $str.=subst(...) # modifies $str Luke
Re: regexp abbreviations matching
Hans Ginzel writes:
> Hello,
>
>I am missing, in Perl5, some shortcut for matching not whole word,
> e.g.:
>
> /^--v(?:e(?:r(?:s(?:i(?:on?)?)?)?)?)?$/
>
> Would there be something in Perl6?
Well, I don't think there's an *exact* substitute for that maximally
efficient pattern (but I'm no regex guru), but this ought to work:
/^ --(v\w*): <( 'version'.substr(0, $1.chars) eq $1 )> $/
And you could always write a rule:
rule partial ($str) {
$str.substr(0,1) ?
}
Then you could just write:
/^-- $/
Luke
Re: enhanced open-funktion
[EMAIL PROTECTED] 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
Re: regexp abbreviations matching
Luke Palmer writes:
> Hans Ginzel writes:
> > Hello,
> >
> >I am missing, in Perl5, some shortcut for matching not whole word,
> > e.g.:
> >
> > /^--v(?:e(?:r(?:s(?:i(?:on?)?)?)?)?)?$/
> >
> > Would there be something in Perl6?
>
> Well, I don't think there's an *exact* substitute for that maximally
> efficient pattern (but I'm no regex guru), but this ought to work:
>
> /^ --(v\w*): <( 'version'.substr(0, $1.chars) eq $1 )> $/
>
> And you could always write a rule:
>
> rule partial ($str) {
> $str.substr(0,1) ?
> }
Except that that particular rule results in an infinite loop :-)
rule partial ($str) {
>
| $str.substr(0,1) ?
}
Luke
Cartesian products? [Especially wrt iterations]
I apologize in advance for posting yet another "suggestion" without having
full knowledge of all apocalypses, and I fear (for a very positive
meaning of "fear") that the answer will be: "but that is already
available".
Well, the point is that I wonder wether Perl6 will support cartesian
products between lists, i.e. an infix operator that will return a list of
arrayrefs "containing" ordered pairs from the originating lists.
Now, one possible difficulty with such an operator would be wrt what to do
with applying it twice or even more times. One would reasonably want it to
be associative in the obvious sense, but this won't happen (because
mathematically speaking (AxA)xA and Ax(AxA) are associative "only" up to
a *natural* isomorphism, which doesn't make much difference,
mathematically speaking, but indeed it does in a computer programming
context).
However I already know that I'll be told that I can cook up something like
that myself. But to be fair I think that the context in which such a beast
would be most useful would be that of iterating over multiple variables,
so one (well, I for one!) could be content with a special syntax for that,
instead.
Put more clearly, it is now common to see things like:
for my $x (1..10) {
for my $y (5..20) {
for my $text (qw/foo bar baz/) {
do_stgh_with $x, $y, $text;
}
}
}
and it would be very much in the phylosophy of Perl to allow for a very
concise syntax to obtain the same effect. I am aware of the zip operator,
but AFAICT it solves an equally common but completely different problem...
Michele
--
The amount of repetition repetition isn't that great.
- Ignacy Sawicki in comp.text.tex
thread "Bug in FeynMF's Queues?"
Re: enhanced open-funktion
On Tue, 13 Jul 2004 [EMAIL PROTECTED] 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)"
Re: enhanced open-funktion
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
Re: enhanced open-funktion
On Tue, Jul 13, 2004 at 03:41:54PM +0200, Michele Dondi wrote:
> On Tue, 13 Jul 2004 [EMAIL PROTECTED] 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 = <>;
while (<$ARGS>) {
# ...
}
}
Not much different is it?
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Cartesian products? [Especially wrt iterations]
--- Michele Dondi <[EMAIL PROTECTED]> wrote: > I apologize in advance for posting yet another "suggestion" without > having full knowledge of all apocalypses, and I fear (for a very > positive meaning of "fear") that the answer will be: "but that is > already available". Using google(+perl6 +"cartesian product") would have led you to the conclusion that this is already included. I hope this is horribly wrong, since the syntax is a little bewildering. > Well, the point is that I wonder wether Perl6 will support cartesian > products between lists, i.e. an infix operator that will return a > list of arrayrefs "containing" ordered pairs from the originating > lists. See Luke Palmer's "Outer product considered useful" post: http://www.mail-archive.com/[EMAIL PROTECTED]/msg15513.html =Austin
Re: Cartesian products? [Especially wrt iterations]
On Tue, Jul 13, 2004 at 03:31:57PM +0200, Michele Dondi wrote:
> Put more clearly, it is now common to see things like:
>
> for my $x (1..10) {
> for my $y (5..20) {
> for my $text (qw/foo bar baz/) {
> do_stgh_with $x, $y, $text;
> }
> }
> }
>
> and it would be very much in the phylosophy of Perl to allow for a very
> concise syntax to obtain the same effect. I am aware of the zip operator,
> but AFAICT it solves an equally common but completely different problem...
Are you sure?
for zip(1..10, 5..20, <>) -> $x, $y, $text {
do_something_with $x,$y,$text;
}
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: enhanced open-funktion
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)
Re: Cartesian products? [Especially wrt iterations]
On Tue, 13 Jul 2004, Austin Hastings wrote:
> Using google(+perl6 +"cartesian product") would have led you to the
> conclusion that this is already included. I hope this is horribly
> wrong, since the syntax is a little bewildering.
[...]
> See Luke Palmer's "Outer product considered useful" post:
> http://www.mail-archive.com/[EMAIL PROTECTED]/msg15513.html
That's exactly the point! I wish too there were a more intuitive syntax,
possibly even employing a predefined array variable if none is
explicitly specified...
On Tue, 13 Jul 2004, Jonathan Scott Duff wrote:
> > and it would be very much in the phylosophy of Perl to allow for a very
> > concise syntax to obtain the same effect. I am aware of the zip operator,
> > but AFAICT it solves an equally common but completely different problem...
>
> Are you sure?
>
> for zip(1..10, 5..20, <>) -> $x, $y, $text {
>do_something_with $x,$y,$text;
> }
Not sure at all: admittedly I may well be one of the less informed ones
about Perl6 here. Though as far as I can understand zip() is for iterating
*in parallel*, and both other replies here and discussion previously held
here seem to indicate that it is so.
Michele
--
> Una gran americanata quello della cottura dell'Hot-dog con i gas di scarico
> della turbina
Una strunzata in piu' tanto gia' mangiano delle schifezze
in piu' condite con kerosene...
- Natale Novello su it.hobby.modellismo, "Re: Video spettacolare in volo"
Re: enhanced open-funktion
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
Re: Cartesian products? [Especially wrt iterations]
Jonathan Scott Duff writes:
> On Tue, Jul 13, 2004 at 03:31:57PM +0200, Michele Dondi wrote:
> > Put more clearly, it is now common to see things like:
> >
> > for my $x (1..10) {
> > for my $y (5..20) {
> > for my $text (qw/foo bar baz/) {
> > do_stgh_with $x, $y, $text;
> > }
> > }
> > }
> >
> > and it would be very much in the phylosophy of Perl to allow for a very
> > concise syntax to obtain the same effect. I am aware of the zip operator,
> > but AFAICT it solves an equally common but completely different problem...
>
> Are you sure?
>
> for zip(1..10, 5..20, <>) -> $x, $y, $text {
>do_something_with $x,$y,$text;
> }
That does a different thing entirely. Allow me to demonstrate, using
C that I proposed:
for zip(1..3, 4..6) -> $x, $y {
say "$x,$y";
}
1,4
2,5
3,6
for outer(1..3, 4..6) -> $x, $y {
say "$x,$y";
}
1,4
1,5
1,6
2,4
2,5
2,6
3,4
3,5
3,6
The essential difference between the lists that zip and outer generate
is the essential difference between the outer and inner products. outer
expands an index while zip collapses an index.
Note also that all arguments to zip ought to be the same length (and if
not, they are finessed into bein g so), where this restriction desn't
apply to outer.
Luke
Re: Cartesian products? [Especially wrt iterations]
--- Michele Dondi <[EMAIL PROTECTED]> wrote:
> On Tue, 13 Jul 2004, Austin Hastings wrote:
>
> > Using google(+perl6 +"cartesian product") would have led you to the
> > conclusion that this is already included. I hope this is horribly
> > wrong, since the syntax is a little bewildering.
> [...]
> > See Luke Palmer's "Outer product considered useful" post:
> > http://www.mail-archive.com/[EMAIL PROTECTED]/msg15513.html
>
> That's exactly the point! I wish too there were a more intuitive
> syntax, possibly even employing a predefined array variable if none
> is explicitly specified...
Boggle! While C may not be totally intuitive, it's not far off.
Likewise, the latin-1 version is pretty good:
for @x × @y × @z -> $x, $y, $z {
...
}
Is there some even more intuitive way than this?
> On Tue, 13 Jul 2004, Jonathan Scott Duff wrote:
>
> > Are you sure?
> >
> > for zip(1..10, 5..20, <>) -> $x, $y, $text {
> >do_something_with $x,$y,$text;
> > }
>
> Not sure at all: admittedly I may well be one of the less informed
> ones about Perl6 here. Though as far as I can understand zip() is for
> iterating *in parallel*, and both other replies here and discussion
> previously held here seem to indicate that it is so.
No, ¥ (C) is wrong for this. (It's the inner product, so it really
ought to be '·' (C) except for the wierd origin.)
=Austin
Re: enhanced open-funktion
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
Re: enhanced open-funktion
--- Larry Wall <[EMAIL PROTECTED]> 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
Re: enhanced open-funktion
On Tue, Jul 13, 2004 at 10:41:32AM -0700, Austin Hastings wrote:
: --- Larry Wall <[EMAIL PROTECTED]> 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
Re: enhanced open-funktion
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
Re: Cartesian products? [Especially wrt iterations]
Luke Palmer skribis 2004-07-13 10:28 (-0600):
> for outer(1..3, 4..6) -> $x, $y {
> say "$x,$y";
> }
> 1,4
> 1,5
> 1,6
> 2,4
> 2,5
> 2,6
> 3,4
> 3,5
> 3,6
So outer is somewhat like {} in shell globs?
perl -le'print for glob "{1,2,3},{4,5,6}"'
Juerd
Re: enhanced open-funktion
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 = ;
print (append $outfile): @lines;
Or equivalently:
==>
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 {...}
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
Re: enhanced open-funktion
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 = ;
> print (append $outfile): @lines;
> Or equivalently:
> ==>
> 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 {...}
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 { ... }
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
Re: enhanced open-funktion
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
Re: push with lazy lists
On 7/12/04, Austin Hastings wrote: --- Larry Wall <[EMAIL PROTECTED]> wrote: The hard part being to pick a random number in [0,Inf) uniformly. :-) Half of all numbers in [0, Inf) are in the range [Inf/2, Inf). Which collapses to the range [Inf, Inf). Returning Inf seems to satisfy the uniform distribution requirement: if you have a number you're waiting to see returned, just wait a bit longer... I like the 1/n trick used in the Perl Cookbook (Picking a Random Line from a File). We could apply the same idea here: rand($_)<1 && ($chosen=$_) for 1...Inf; All right, it would take a bit longer for your program to run, but that's a performance issue for them to sort out on *-internals. -David "sure Moore's Law will deal with it in a year or two" Green
Re: The .bytes/.codepoints/.graphemes methods
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Larry Wall) wrote: >On Tue, Jun 29, 2004 at 10:52:34AM -0500, Jonathan Scott Duff wrote: >: :u0 # use bytes (. is byte) >: :u1 # level 1 support (. is codepoint) >: :u2 # level 1 support (. is grapheme) >: :u3 # level 1 support (. is language dependent) > >These modifiers might get renamed to match whatever b/c/g/w convention >we come up with pragmas. The levels aren't all that intuitive, though >there is a kind of progression of semantic complexity that would get >lost with ordinary names. bytes codepts graphemes langdepends That's a kind of progression. And "codepts" seems a natural enough abbreviation, though I don't really know what to do with language_ dependent_thingummies. Though with less typing, the initials b < c < g < l give the same progression. -David "except for encodings where c
Re: push with lazy lists
David Green writes: > On 7/12/04, Austin Hastings wrote: > >--- Larry Wall <[EMAIL PROTECTED]> wrote: > > > >> The hard part being to pick a random number in [0,Inf) uniformly. :-) > > > >Half of all numbers in [0, Inf) are in the range [Inf/2, Inf). Which > >collapses to the range [Inf, Inf). Returning Inf seems to satisfy the > >uniform distribution requirement: if you have a number you're waiting > >to see returned, just wait a bit longer... > > I like the 1/n trick used in the Perl Cookbook (Picking a Random Line from > a File). We could apply the same idea here: > > rand($_)<1 && ($chosen=$_) for 1...Inf; I just have to say, I am forever indebted to that algorithm. Luke
Re: push with lazy lists
> >--- Larry Wall <[EMAIL PROTECTED]> wrote: > >> The hard part being to pick a random number in [0,Inf) uniformly. :-) > > > >Half of all numbers in [0, Inf) are in the range [Inf/2, Inf). Which > >collapses to the range [Inf, Inf). Returning Inf seems to satisfy the > >uniform distribution requirement: if you have a number you're waiting > >to see returned, just wait a bit longer... > > I like the 1/n trick used in the Perl Cookbook (Picking a Random Line from > a File). We could apply the same idea here: > > rand($_)<1 && ($chosen=$_) for 1...Inf; I don't believe that that could give you an value ... > All right, it would take a bit longer for your program to run, but that's > a performance issue for them to sort out on *-internals. Like, it would take a bit longer than your lifetime :-)? >-David "sure Moore's Law will deal with it in a year or two" Green 'And my new '986 does the infinite loop in under 3.5 seconds' :-) To repeat Dave and myself - if @x = 1 .. Inf; then rand(@x) should be Inf, and so print $x[rand(@x)]; should give Inf, as the infinite element of @x is Inf. But maybe we could get an index of Inf working like -1 (ie. the last value): @x = 1 .. Inf; push @x, "a"; print $x[Inf]; would print an "a" ... although, on this line of reasoning, print $x[rand(@x)]; would always print "a" I believe that an array should get an .rand-Method, which could do the right thing. @x= (1 .. Inf, "b", -Inf .. -1, "c", 1 .. Inf); print $x[rand(@x)],"\n" while (1); could give Inf Inf -Inf b c Inf -Inf and so on - an "random" element of a random part of the array, and an infinite list gives Inf (or -Inf) as a random element (as explained above in this thread). So an array would have to know of how many "pieces" it is constructed, and then choose an element among the pieces ... I'd think that's reasonable, isn't it? Regards, Phil
