Re: enhanced open-funktion
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)
Re: scalar subscripting
Larry Wall wrote:
I suppose another approach is simply to declare that dot is always a
metacharacter in double quotes, and you have to use \. for a literal
dot, just as in regexen. That approach would let us interpolate
things like .foo without a variable on the left. That could cause
a great deal of cultural confusion in the short term, however.
[...]
Ouch. I'm thinking we allow $foo.bar in both strings and regexen, but
not .bar in either case. Gotta use $_.bar inside strings and regexen.
(Or $(.bar) would work too.) Possibly we even complain about /.bar/
and force them to write /. bar/.
Please, think of C. Dots with whitespace or end-of-string after them should
just be literal dots in qq strings. Dots should always be literals in
q() strings, of course. And dots are /already/ metacharacters in
regex^Wrules; forcing a space after the dot isn't giving the power of
formatting to the user; it's forcing formatting upon them that they
don't want. (I don't remember if there's an adverb to treat spaces as
literals, but if not, there should be.)
I think method calls in strings should be "Foo's bar is $($foo.bar).",
plain and simple. Dot is too useful here already. @{[...]} needed to
be replaced with something easier to type, and with clearer (and
cleaner) semantics. We did that; $(...) is far better. Not requiring a
set off for method calls is Huffman coding the wrong direction, unless
you can find one that won't disturb useful things that you'd want in
double-quotes -- which includes patterns common in any natural language,
which includes even the literal versions of << / >> (which I can't type
easily at the moment).
-=- James Mastros
Re: enhanced open-funktion
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 ([EMAIL PROTECTED]) Systems and Network Administrator UNICO Computer Systems Melbourne, Australia. Phone: +61-3-9865-9116
Re: enhanced open-funktion
On Thu 15 Jul 2004 11:42, Michele Dondi <[EMAIL PROTECTED]> 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 BrandAmsterdam 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/[EMAIL PROTECTED]/ [EMAIL PROTECTED] send smoke reports to: [EMAIL PROTECTED], QA: http://qa.perl.org
Re: enhanced open-funktion
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
Re: enhanced open-funktion
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
Re: push with lazy lists
On Wed, 14 Jul 2004, Ph. Marek wrote: > Please take my words as my understanding, ie. with no connection to > mathmatics or number theory or whatever. I'll just say what I believe is > practical. As a side note, being what one would probably call a mathematically oriented person, it is very natural for me, dealing with programming languages to notice the mathematical aspects of them. To be more precise, and without delving into the details of the actual nature of mathematical objects and related phylosophical ideas, for me (and not only for me) mathematics is *also* a language, just as natural as many so-called "natural languages". Also, mathematics, as a language indeed is one that aims at obtaining the most possible expressiveness with the least possible verbose expense. In this sense it should be very interesting from the perspective of Perl... This is why *for example* I was so interested in the discussion about "outer products" (but then I wouldn't call them so!) Hope not to have contributed negatively to the noise/signal ratio on list... 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: push with lazy lists
On Wednesday 14 July 2004 12:58 pm, Brent 'Dax' Royal-Gordon wrote: > Andrew Rodland wrote: > > So if we have @x = [1, 3, 5, 6 .. 9, 10 .. Inf, 42]; > > ... > > > 42 is just one number, so questions of indexing > > it are moot, but its "distance" from the left is Inf. So, there's no way > > to access the 42 by any positive index of @x, and no way to ever get it > > by successive "shift". > > Sure, but shouldn't @x[-1] give 42? Yeah. If I didn't write that, I certainly meant it. --Andrew
Re: enhanced open-funktion
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
Re: enhanced open-funktion
--- Smylers <[EMAIL PROTECTED]> 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
Re: enhanced open-funktion
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 <[EMAIL PROTECTED]> Perl and Parrot hacker Oceania has always been at war with Eastasia.
Re: enhanced open-funktion
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. [EMAIL PROTECTED]:~/tmp/example$ ls -R * |: usr |/usr: bin |/usr/bin: foo Juerd
Re: enhanced open-funktion
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
