Re: Arglist I/O [Was: Angle quotes and pointy brackets]
On Fri, 3 Dec 2004, Larry Wall wrote:
On Fri, Dec 03, 2004 at 06:43:05PM +, Herbert Snorrason wrote:
: This whole issue kind of makes me go 'ugh'. One of the things I like
: best about Perl is the amazing simplicity of the input construct.
Hmm.
while () {...}
for .lines {...}
Looks like a wash to me.
Partly it does. The point is that not only the is simple, but that it
is also visually distinctive, which is important IMHO.
Obviously the new proposal of unary C= is just as good from this point
of view...
: Replacing that with something that not only is object oriented, but on
: top of that also LOOKS object oriented is bound to be a loss. It's
: going to be that bit longer to write, and not the least bit easier to
: understand.
Really? I dare you to show those two lines to any random
computer-literate but non-Perl-speaking stranger and see which one
they understand better.
Of course they'd understand better the latter, but I think that there's a
limit to non-Perl-speaking-people-friendship. After all this may be useful
for learning perl, but learning it to a good degree would always involve
getting acquainted with quite a lot of typical idioms, so this does not
make much of a point IMHO, provided that when a typical user becomes
familiar with those idioms he can perceive (i) how good they look in
source code (ii) how useful they result in practice.
It's all cargo cult at that level anyway, so whether it looks OO or not
is really completely immaterial to its usability.
Indeed it's not *purely* a matter of looking OO, but of looking yet
another more-or-less alphabetic string (yes, even with a prepended point:
it's just not as markedly distinctive!). As I said, is deeply etched in
Perl programmers' cortex as an input operator. In other words it may well
be cargo cult, but not in a totally negative acceptation: I mean... till
it works, and works well as it currently does!
And I don't buy the nuclear blackmail argument either. I'll start
worrying about people switching to Python and Ruby when those languages
get a clue about how natural languages work. As far as I know, there's
OTOH, as a side note, but not a totally unrelated one, I guess, one should
pay some attention not to exaggerate following natural languages
principles in designing programming languages: granted, I appreciate their
pervasiveness in (current) perl and indeed probably this is one of the
reasons I love it. But I think that there are some natural limits to this
as well: AFAIK any attempt to overcome them was basically a failure. We
want the *right* mixture of conciseness, intutivity, clarity instead. In
this sense a construct like
while () {
...
}
really doesn't resamble any natural language construct as far as I can
see, but indeed it's an idiom that perl programmers easily become familiar
with and like to use... well, I think so!
Michele
--
I hold a square measuring 10x10 metres away from a person who is standing
100 metres away.
I ask them to shoot the square with a high-accuracy gun.
Don't stand there holding the square when they are shooting...
- Robert Israel in sci.math, Re: Scaling
Re: Topification [Was: Arglist I/O [Was: Angle quotes and pointy brackets]]
Austin Hastings wrote:
I'll guess that you're pointing at
.:send_one($_);
Which supposedly uses topic to resolve .:send_one into $this.send_one.
If that works, then I'm happy -- I like being able to control topic and
$_ differently. But if Cfor changes topic, then what?
OUTER::.:send_one($_);
Yuck.
I believe it needs to be
method send ($self: [EMAIL PROTECTED]) {
$self.:send_one(BEGIN);
for @data {
$self.:send_one($_);
}
$self.:send_one(END);
}
While that works (I think it works anyway), its debatable if it's nice
or not. The first and last calls to .:send_one shouldn't need the $self,
but I put it there because if you use the $self inside the for in a
method that short, it's nice and clear to have it outside it as well.
I suspect the original example expands the for loop into the equivalent of:
for @data - $item {
$item.:send_one($item);
}
And it doesn't take a $larry to figure out that this isn't going to make
the compiler very happy, as it's most likely a violation of class access
control, I would have thought.
So Luke, am I right?
Re: Arglist I/O [Was: Angle quotes and pointy brackets]
Larry Wall wrote:
But here's the kicker. The null filename can again represent the
standard filter input, so we end up with Perl 5's
while () {...}
turning into
for = {...}
Two more issues: idiom, and topification
= Topification:
There are cases in P5 when I *don't* want
while () {...}
but prefer
while ($input = ) {...}
so that I can have something else be the topic. Every example to date
has used Cfor:
for .lines {...}
but that sets the topic. I'm a little fuzzy on this, but doesn't Cfor
play topic games even in this?
for .lines - $input { ... $input ... }
That is, even though $_ remains unaffected, doesn't this affect
smartmatch etc.?
= Idiom:
The other concern is idiom. Using Cfor suggests start at the
beginning, continue to the end. OTOH, using Cwhile is a little
weaker -- keep doing this until it's time to stop. Obviously they'll
usually be used in the same way:
for = {...} vs. while () {...}
This seems a subtle concern, and maybe it's just my latent fear of
change making me uncomfortable, but I actually *think* in english -- not
that it does much good -- and this isn't how I think.
Can we ditch Cfor in the examples in favor of Cwhile, for a while? :)
=Austin
Re: Arglist I/O [Was: Angle quotes and pointy brackets]
On Dec 6, 2004, at 7:38 AM, Austin Hastings wrote:
for = {...}
I dub the...the fish operator!
:-)
David
Re: Arglist I/O [Was: Angle quotes and pointy brackets]
On Mon, Dec 06, 2004 at 09:06:22AM -0800, David Wheeler wrote:
: On Dec 6, 2004, at 7:38 AM, Austin Hastings wrote:
:
:for = {...}
:
: I dub the...the fish operator!
:
: :-)
Mmm. Next thing you'll know, people will name their files oddly just so
they can write things like:
for =///º {...}
for =|||' {...}
for =###* {...}
for =]]]° {...}
for =)))º {...}
Larry
Topification [Was: Arglist I/O [Was: Angle quotes and pointy brackets]]
On Mon, Dec 06, 2004 at 10:38:10AM -0500, Austin Hastings wrote:
: Two more issues: idiom, and topification
:
: = Topification:
:
: There are cases in P5 when I *don't* want
:
: while () {...}
:
: but prefer
:
: while ($input = ) {...}
:
: so that I can have something else be the topic. Every example to date
: has used Cfor:
:
: for .lines {...}
:
: but that sets the topic. I'm a little fuzzy on this, but doesn't Cfor
: play topic games even in this?
:
: for .lines - $input { ... $input ... }
:
: That is, even though $_ remains unaffected, doesn't this affect
: smartmatch etc.?
Currently it does. There have been some rumblings in the design team
that maybe it shouldn't. But it occurs to me that this might be another
spot to have our cake and eat it to. We could say that
for @foo - $input { ... $input ... }
doesn't set the topic in the block by default. However, methods do set
the topic (though there have been rumblings about that too). So we could
simply say that pointy subs can also be pointy methods if you specify
an invocant:
for @foo - $input: { ... $input and $_ ... }
I think I like that, but it needs to be thunk about some more. The downside
is that it's rather subtle. The upside is that it falls out of existing
rules, and lets - map more naturally in the way people expect. I don't
think people will naturally expect - to clobber $_.
Larry
while idiom [Was: Arglist I/O [Was: Angle quotes and pointy brackets]]
On Mon, Dec 06, 2004 at 10:38:10AM -0500, Austin Hastings wrote:
: = Idiom:
:
: The other concern is idiom. Using Cfor suggests start at the
: beginning, continue to the end. OTOH, using Cwhile is a little
: weaker -- keep doing this until it's time to stop. Obviously they'll
: usually be used in the same way:
:
: for = {...} vs. while () {...}
:
: This seems a subtle concern, and maybe it's just my latent fear of
: change making me uncomfortable, but I actually *think* in english -- not
: that it does much good -- and this isn't how I think.
:
: Can we ditch Cfor in the examples in favor of Cwhile, for a while? :)
Okay. Have an example:
while =$IN - $line {...}
I think that works. I'm back to thinking unary = in scalar context iterates
like p5's , and you should use extraordinary means to get extraordinary
results:
while file $IN - $blob {...}
while slurp $IN - $bigblob {...}
Larry
Re: Arglist I/O [Was: Angle quotes and pointy brackets]
Or even the dead fish operator:
while =###x - $net {...}
And here's a flounder:
while =:
Larry
Re: Arglist I/O [Was: Angle quotes and pointy brackets]
David Wheeler wrote:
On Dec 6, 2004, at 7:38 AM, Austin Hastings wrote:
for = {...}
I dub the...the fish operator!
:-)
Back before there was a WWW, I used an editor called tgif. It was
written in france, and part of the idiom was to have two GUI buttons
showing respectively the head ( * ) and tail ( ( ) parts of a
fish. This were graphical images, please forgive my poor ascii drawing.
It took me a while to figure it out, but it was a cute bit of
bilingualism. (Or perhaps it was a bit of bilingual cute-ism...)
=Austin
Re: Topification [Was: Arglist I/O [Was: Angle quotes and pointy brackets]]
Larry Wall writes:
Currently it does. There have been some rumblings in the design team
that maybe it shouldn't. But it occurs to me that this might be another
spot to have our cake and eat it to. We could say that
for @foo - $input { ... $input ... }
doesn't set the topic in the block by default. However, methods do set
the topic (though there have been rumblings about that too). So we could
simply say that pointy subs can also be pointy methods if you specify
an invocant:
for @foo - $input: { ... $input and $_ ... }
I think I like that, but it needs to be thunk about some more. The downside
is that it's rather subtle. The upside is that it falls out of existing
rules, and lets - map more naturally in the way people expect. I don't
think people will naturally expect - to clobber $_.
Considering that I was the rumbler, I'll try to stay concise. Don't
think that this is anything more than a stormy brain, though.
I really like the fact that for always topicalizes. I like it because
it forces refactors where they ought to be happening. I always get
confused when I see:
for (@array) {
for my $row (@{$data-[$_]}) {
for my $element (@$row) {
foobar($_) if $element;
}
}
}
It works that way in natural languages too. If you try to use it too
remotely, you just confuse everybody. In particular:
For each element in @array, look up the corresponding $row in $data,
and for each $element in the $row, call foobar on it if $element is
true.
Call foobar on what?
The remaining problem is what to do about unary dot. Repeated here for
the, er, benefit? of p6l:
class Duple {
has $.left;
has $.right;
method perform (oper) {
oper($.left);
oper($.right);
}
}
Let's change that into a Tuple class:
class Tuple {
has @.elems;
method perform (oper) {
for @.elems {
.perform($_);
}
}
}
Can you find the mistake?
Luke
Re: while idiom [Was: Arglist I/O [Was: Angle quotes and pointy brackets]]
On Mon, Dec 06, 2004 at 09:56:57AM -0800, Larry Wall wrote:
On Mon, Dec 06, 2004 at 10:38:10AM -0500, Austin Hastings wrote:
: Can we ditch Cfor in the examples in favor of Cwhile, for a while? :)
Okay. Have an example:
while =$IN - $line {...}
I think that works. I'm back to thinking unary = in scalar context iterates
like p5's
What would these do?
while =$IN - $l1,$l2 {...}
while =$IN - @x {...}
That first one seems particularly useful. I'm not exactly sure what
the second one should do, but it seems like it should be similar to
{ my @x = $IN.slurp; ... }
Can it be that unary = in n-ary context iterates like p5's except
when n == Inf or n == 0 (which are list and void context I guess) ?
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: while idiom [Was: Arglist I/O [Was: Angle quotes and pointy brackets]]
On Mon, Dec 06, 2004 at 12:45:18PM -0600, Jonathan Scott Duff wrote:
: On Mon, Dec 06, 2004 at 09:56:57AM -0800, Larry Wall wrote:
: On Mon, Dec 06, 2004 at 10:38:10AM -0500, Austin Hastings wrote:
: : Can we ditch Cfor in the examples in favor of Cwhile, for a while? :)
:
: Okay. Have an example:
:
: while =$IN - $line {...}
:
: I think that works. I'm back to thinking unary = in scalar context iterates
: like p5's
:
: What would these do?
:
: while =$IN - $l1,$l2 {...}
: while =$IN - @x {...}
:
: That first one seems particularly useful. I'm not exactly sure what
: the second one should do, but it seems like it should be similar to
: { my @x = $IN.slurp; ... }
The Cwhile statement is not an arbiter of lists. It want a scalar
value that can play the bool role. Assuming that $IN is really $*IN,
they would both fail because you're trying to bind a scalar string
to a signature that doesn't accept a single scalar string. It would
be exactly like
sub foo($I1, $I2) {...}
foo(#!/usr/bin/perl\n); # missing $I2
sub bar(@x) {...}
bar(#!/usr/bin/perl\n); # Trying to bind non-string to @x
That being said, if =$iterator returns a list of array references, the
second one would work. I don't see any way to make the first one work.
: Can it be that unary = in n-ary context iterates like p5's except
: when n == Inf or n == 0 (which are list and void context I guess) ?
You mean slurps all the values and then throws away all but n of them?
That's how p5's currently behaves. Or did you mean scalar ?
In any event, I don't think Cwhile is ever going to provide an n-ary
context to whatever it wants a boolean value from. That's what Cfor
is for.
Larry
Re: while idiom [Was: Arglist I/O [Was: Angle quotes and pointy brackets]]
On Mon, Dec 06, 2004 at 10:59:18AM -0800, Larry Wall wrote:
On Mon, Dec 06, 2004 at 12:45:18PM -0600, Jonathan Scott Duff wrote:
: On Mon, Dec 06, 2004 at 09:56:57AM -0800, Larry Wall wrote:
: On Mon, Dec 06, 2004 at 10:38:10AM -0500, Austin Hastings wrote:
: : Can we ditch Cfor in the examples in favor of Cwhile, for a while?
:)
:
: Okay. Have an example:
:
: while =$IN - $line {...}
:
: I think that works. I'm back to thinking unary = in scalar context
iterates
: like p5's
:
: What would these do?
:
: while =$IN - $l1,$l2 {...}
: while =$IN - @x {...}
:
: That first one seems particularly useful. I'm not exactly sure what
: the second one should do, but it seems like it should be similar to
: { my @x = $IN.slurp; ... }
The Cwhile statement is not an arbiter of lists.
Okie.
In any event, I don't think Cwhile is ever going to provide an n-ary
context to whatever it wants a boolean value from. That's what Cfor
is for.
Somehow I knew you were going to say that. I'm just being reluctant
to use Cfor for something I've been using Cwhile for all this time.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Topification [Was: Arglist I/O [Was: Angle quotes and pointy brackets]]
Luke Palmer wrote:
The remaining problem is what to do about unary dot. Repeated here for
the, er, benefit? of p6l:
class Duple {
has $.left;
has $.right;
method perform (oper) {
oper($.left);
oper($.right);
}
}
Let's change that into a Tuple class:
class Tuple {
has @.elems;
method perform (oper) {
for @.elems {
.perform($_);
}
}
}
Can you find the mistake?
Well it's not using oper on the elems anymore.
method perform (oper) {
for @.elems {
oper($_);
}
}
But I don't think that was the mistake you were talking about. And I
don't see what it has to do with unary dot either, because you don't
need to use unary dot to implement that method. Unless each member of
@.elems is a Duple, in which case the class isn't one I'd call Tuple.
Sorry, nitpicking level seems to be set to 9 at the moment. What did you
mean?
Re: Topification [Was: Arglist I/O [Was: Angle quotes and pointy brackets]]
Matthew Walton writes:
Luke Palmer wrote:
The remaining problem is what to do about unary dot. Repeated here for
the, er, benefit? of p6l:
class Duple {
has $.left;
has $.right;
method perform (oper) {
oper($.left);
oper($.right);
}
}
Let's change that into a Tuple class:
class Tuple {
has @.elems;
method perform (oper) {
for @.elems {
.perform($_);
}
}
}
Can you find the mistake?
Well it's not using oper on the elems anymore.
That's mostly because I really screwed up the example. Mind, it was
very, very early in the morning when I wrote this. Let's try again.
(This is a pretty trivial example, but the problem only gets worse as we
approach real life).
class MyStream {
has $.stream;
method :send_one ($item) {
$.stream.send($item);
}
method send ([EMAIL PROTECTED]) {
.:send_one(BEGIN);
for @data {
.:send_one($_);
}
.:send_one(END);
}
}
Luke
Re: Topification [Was: Arglist I/O [Was: Angle quotes and pointy brackets]]
Luke Palmer wrote:
class MyStream {
has $.stream;
method :send_one ($item) {
$.stream.send($item);
}
method send ([EMAIL PROTECTED]) {
.:send_one(BEGIN);
for @data {
.:send_one($_);
}
.:send_one(END);
}
}
I'll guess that you're pointing at
.:send_one($_);
Which supposedly uses topic to resolve .:send_one into $this.send_one.
If that works, then I'm happy -- I like being able to control topic and
$_ differently. But if Cfor changes topic, then what?
OUTER::.:send_one($_);
Yuck.
=Austin
Re: Arglist I/O [Was: Angle quotes and pointy brackets]
Okay, maybe I should have gone to bed, but I kept thinking about this.
I'm starting to suspect it's time to haul out the operator I've
been holding in reserve for lo these many years now, the unary =.
Suppose we say that it iterates iterators, but also it recognizes
certain things that aren't iterators and turns them into iterators
and iterates them. So you can say
for =$*IN {...}
for =$*ARGS {...}
if you like, but it also recognizes filenames, and lists of filehandles,
and lists of filenames, and in list context turns them into lists of
lines:
for =foo.c {...}
for =foo.c foo.h {...}
for =«$foo.c $foo.h» {...}
for =['foo.c', 'foo.h'] {...}
for =['.myrc', @*ARGS] {...}
for [EMAIL PROTECTED] {...}
You can think of the = as a picture of the lines in the file, and
read it lines of. Well, in list context anyway. In scalar context,
it would do a slurp:
$file = =foo.c;
But here's the kicker. The null filename can again represent the
standard filter input, so we end up with Perl 5's
while () {...}
turning into
for = {...}
It's just all the magic is done by the = operator rather than the
, which is just a plain old ordinary null string inside newfangled
angle quotes. I suppose =() or =[] or = would work just as well,
but somehow = is what I expect convention to settle on, for certain
values of hysterical and raisins.
And yes, I've looked at every other character on the keyboard, and
several that aren't on the keyboard. And no, I don't think it'll
cause many parsing difficulties since we changed the parsing rules
on methods to require parentheses if there are arguments. It's only
a problem after 0-or-1-ary operators, and not really a problem there,
since the default is to look for a term, and there aren't many 0-or-1-ary
operators you'd want to assign to anyway. In particular, you can say
things like:
print =foo.c;
And I don't think it'll be visually confusing to people who put spaces
on both sides of their assignment operators.
Larry
Re: Arglist I/O [Was: Angle quotes and pointy brackets]
On Fri, Dec 03, 2004 at 06:38:42PM -0800, Larry Wall wrote:
: Might even just be a global multi sub that defaults to $*ARGS:
:
: multi sub *lines (IO ?$handle = $*ARGS) {...}
: multi sub *lines (Str $filename) {...}
: multi sub *lines (IO @handle) {...}
: multi sub *lines (Str @filenames) {...}
:
: Then the filter call would be quite hypoallergenic:
:
: for lines {...}
Except that won't parse right, drat it. It won't know whether to expect
a term or an operator at the left bracket. Can't use a 0-or-1-ary
as the last thing in the list. That was the advantage of .lines, which
we could tell had no arguments, since methods with arguments must use
parens.
Don't wanna go back to bare * either; I've since made it a synonym
for Any. Plus it also suffers the 0-or-1 problem. It would still
work as a unary, if we can figure out something really short to mean
$*ARGS.
[Much bogus random brainstorming deleted.]
Well, I just need to think about it some more. I've already believed
six impossible things after dinner, so maybe I'd better go to bed.
Larry
Re: Arglist I/O [Was: Angle quotes and pointy brackets]
On Sat, 4 Dec 2004 01:37:00 -0800, Larry Wall [EMAIL PROTECTED] wrote:
for =$*IN {...}
for =$*ARGS {...}
Yay. A generalised form of the input operator, which can create even
handier idioms for simple file processing. Maybe I wasn't clear
enough. My issue wasn't specifically with '.lines' for filter
behaviour -- as a replacement solely for the while () { ... } idiom,
it would be quite adequate. But as a replacement for OPENEDFILE, it
is (IMO) sub-par, and definitely does add to the length of the whole.
As for the nuclear blackmail argument: One of the prime reasons I
like Perl is that different things look different. When everything
starts looking like a method call, that distinction rapidly drops
away.
$file = =foo.c;
Huh. That's really kinda neat.
But here's the kicker. The null filename can again represent the
standard filter input, so we end up with Perl 5's
while () {...}
turning into
for = {...}
Which is really short for 'for [EMAIL PROTECTED] {...}', then?
--
Schwäche zeigen heißt verlieren;
härte heißt regieren.
- Glas und Tränen, Megaherz
Re: Arglist I/O [Was: Angle quotes and pointy brackets]
Larry Wall wrote:
So you can say
for =$*IN {...}
for =$*ARGS {...}
for =foo.c {...}
for =foo.c foo.h {...}
for =«$foo.c $foo.h» {...}
for =['foo.c', 'foo.h'] {...}
for =['.myrc', @*ARGS] {...}
for [EMAIL PROTECTED] {...}
for = {...}
The simplicity is nice, but the visual message is, well, icky.
It might be salvageable by having the ='s balance, yielding:
for =$*IN= {...}
for =$*ARGS= {...}
for =foo.c= {...}
for =foo.c foo.h= {...}
for =«$foo.c $foo.h»= {...}
for =['foo.c', 'foo.h']= {...}
for =['.myrc', @*ARGS]= {...}
for [EMAIL PROTECTED] {...}
for == {...}
That looks better. Might even make the trailing = mean something useful
like auto-chomp.
And I don't think it'll be visually confusing to people who put spaces
on both sides of their assignment operators.
But those of us who often use the horizontal ws to break up the terms on
a line will moderately often not put spaces around our assignments and
less thans.
Okay, this rant is more about the \s\s than \s=\s. To me, it is easier
to understand the grouping of line 1 than line 2 below:
if( $a$b $c$d ) {...}
if( $a $b $c $d ) {...}
In line2, my mind has to stop and ask: is that ($a $b) ($c $d),
or $a ($b $c) $d. It quickly comes to the right answer, but the
question never comes up in the first line. If I wanted to use more
parens for clarity, I'd use LISP.
-- Rod Adams
Re: Arglist I/O [Was: Angle quotes and pointy brackets]
Rod Adams writes:
Okay, this rant is more about the \s\s than \s=\s. To me, it is easier
to understand the grouping of line 1 than line 2 below:
if( $a$b $c$d ) {...}
if( $a $b $c $d ) {...}
In line2, my mind has to stop and ask: is that ($a $b) ($c
$d), or $a ($b $c) $d. It quickly comes to the right answer,
but the question never comes up in the first line. If I wanted to use
more parens for clarity, I'd use LISP.
This is Perl. TMTOWTCI (Clarify It).
if ($a $b) ($c $d) {...}
if $a $b and $c $d{...}
if $a $b$c $d {...}
In particular, you need to ask yourself which you'd rather have:
$a$b with %hkey
$a $b with %hkey
But you might actually have to ask yourself. I'm still not sure... (and
I'm not even paying attention to the left side).
Luke
Re: Arglist I/O [Was: Angle quotes and pointy brackets]
On Fri, Dec 03, 2004 at 06:38:42PM -0800, Larry Wall wrote:
On Fri, Dec 03, 2004 at 06:43:05PM +, Herbert Snorrason wrote:
: This whole issue kind of makes me go 'ugh'. One of the things I like
: best about Perl is the amazing simplicity of the input construct.
Hmm.
while () {...}
for .lines {...}
Looks like a wash to me.
This is a neat win, keyboards favorise alphabetic characters that are
less excentred. Moreover, in some non qwerty layout, to make place for
diacritic characters, some non alphabetic characters are less
accessible, shift or alt-gr is necessary to type them.
Having being used to qwerty keyboards, on a french keyboard, I switch
from azerty to qwerty to program in C or Perl because of their heavy
ratio nonalpha/alpha. But most programmers use their native keyboard
layout.
--
stef
Re: Arglist I/O [Was: Angle quotes and pointy brackets]
On Sat, 04 Dec 2004 11:03:03 -0600, Rod Adams [EMAIL PROTECTED] wrote:
Larry Wall wrote:
for =$*IN {...}
for =$*ARGS {...}
for =foo.c {...}
for =foo.c foo.h {...}
for =$foo.c $foo.h {...}
for =['foo.c', 'foo.h'] {...}
for =['.myrc', @*ARGS] {...}
for [EMAIL PROTECTED] {...}
for = {...}
The simplicity is nice, but the visual message is, well, icky.
It might be salvageable by having the ='s balance, yielding:
for =$*IN= {...}
for =$*ARGS= {...}
hm. we have short and strange FH, for input.. (and for some reason, it
is bracketing! there's no sense at all in it)
..but we have long (and even looking slightly OOish, in perl5 sense) print
FH for output, and noone complained. We still aint going to have funny
syntax for output, and we not going to keep old syntax for input. Why to
reintroduce even more strangeness with that unary =, which is actually a
simple list operator, which doesn't desire for huffmanizing?
I don't think that would hurt anyone
for lines file1 file2 file3 {...}
# or
for files file1 file2 file3 {...}
# or
for lines @*ARGS {...}
# or just that special case:
for lines {...}
but actually everybody just miss that short and strange
while () {...}
and how all other handles would be accessed is much less concern.
it's just a bad and beloved habit, IMHO.
maybe we could make a special case.. (C programmers would be shocked)
for () {...}
Re: Arglist I/O [Was: Angle quotes and pointy brackets]
On Sat, 04 Dec 2004 11:03:03 -0600, Rod Adams [EMAIL PROTECTED] wrote:
Okay, this rant is more about the \s\s than \s=\s. To me, it is easier
to understand the grouping of line 1 than line 2 below:
if( $a$b $c$d ) {...}
if( $a $b $c $d ) {...}
In line2, my mind has to stop and ask: is that ($a $b) ($c $d),
or $a ($b $c) $d. It quickly comes to the right answer, but the
question never comes up in the first line. If I wanted to use more
parens for clarity, I'd use LISP.
I've got used to write it as
if( $a $b and $c $d) {...}
already. if it could help.. :)
Re: Arglist I/O [Was: Angle quotes and pointy brackets]
On Sat, Dec 04, 2004 at 11:02:38PM +0300, Alexey Trofimenko wrote:
: hm. we have short and strange FH, for input.. (and for some reason, it
: is bracketing! there's no sense at all in it)
: ..but we have long (and even looking slightly OOish, in perl5 sense) print
: FH for output, and noone complained. We still aint going to have funny
: syntax for output, and we not going to keep old syntax for input. Why to
: reintroduce even more strangeness with that unary =, which is actually a
: simple list operator, which doesn't desire for huffmanizing?
True, except for the fact that it *is* unary rather than list, so it
doesn't require parens to interpolate =$fh into a list. I had been
thinking that there should be a long form as well, just as we have
both !/not, and ?/true.
: I don't think that would hurt anyone
: for lines file1 file2 file3 {...}
: # or
: for files file1 file2 file3 {...}
: # or
: for lines @*ARGS {...}
: # or just that special case:
:
: for lines {...}
But that last one is the one that *doesn't* work if lines is a list operator.
List operators always expect a term, and {...} is recognized as a statement
block only where an operator is expected.
It would be parsed as:
for lines({...}) ???
: but actually everybody just miss that short and strange
: while () {...}
: and how all other handles would be accessed is much less concern.
: it's just a bad and beloved habit, IMHO.
Definitely beloved. Bad? I dunno. It's definitely visually distinct,
and that's why I put it into Perl that way in the first place. The data
flow of your program is only partially related to the control flow,
and something that is producing asynchronous data needs to stand out.
: maybe we could make a special case.. (C programmers would be shocked)
: for () {...}
I think that should just do nothing, so that a code generator can spit it
out without worrying about the special case. I still think the special
case is either of
for = {...}
or
for lines {...}
at the writer's discretion.
But I do like your lines/files distinction, which = doesn't make. Probably
if we distinguish them as list operators, we make the unary = only do
lines. Then in scalar context it just gives you the next line, which
will be more familiar to people coming from FH think.
I suppose we could also have
for words {...}
for tokens {...}
for paragraphs {...}
for chunks(, :delim(/^^===+\h*\n/)) {...}
etc.
On the other hand, if we follow the Perl 5 model, maybe = always
means chunks, and the filehandle just defaults to chunking into lines
like Perl 5's in the absence of a $/ redefinition. Presumably
words/tokens/lines/paragraphs/files would just synonyms for chunks in
that case. And maybe records/rows for people who don't like chunks. :-)
But I think people would expect something like words to override
the filehandle's natural chunking proclivities at least temporarily
in the case of a scalar input. So I think =$fh means chunks($fh),
the natural chunking of the filehandle (defaulting to lines), while
the words/files/paragraphs do temporary override of chunking policy.
Presumably there are also :words, :files, and :paragraphs adverbs on
the opening of the filehandle to set the default chunking. No reason
to make them different words. Or maybe they're all args to a single
:bywords adverb. And perhaps that also turns on autochomping.
Larry
Re: Arglist I/O [Was: Angle quotes and pointy brackets]
On Sat, Dec 04, 2004 at 11:08:38PM +0300, Alexey Trofimenko wrote:
On Sat, 04 Dec 2004 11:03:03 -0600, Rod Adams [EMAIL PROTECTED] wrote:
Okay, this rant is more about the \s\s than \s=\s. To me, it is easier
to understand the grouping of line 1 than line 2 below:
if( $a$b $c$d ) {...}
if( $a $b $c $d ) {...}
In line2, my mind has to stop and ask: is that ($a $b) ($c $d),
or $a ($b $c) $d. It quickly comes to the right answer, but the
question never comes up in the first line. If I wanted to use more
parens for clarity, I'd use LISP.
I've got used to write it as
if( $a $b and $c $d) {...}
already. if it could help.. :)
I agree with Rod - it is much more readable when there are
no blanks around the and there are blanks around the .
Typing is not the problem as much as reading, however, I choose
the spacing for readability when I type it, deciding what the
base chunks are and putting blanks aound the base chunks but
not within them. Having a few operators that require spacing
will be an extra gotcha to consider in that process, so it
will occassionably lead to syntax errors when I don't consider
the special rule; but it will still lead to less readable code
when I do remember the rule and leave the extra spaces.
--
Re: Arglist I/O [Was: Angle quotes and pointy brackets]
On Sat, Dec 04, 2004 at 01:24:41PM -0800, Larry Wall wrote:
: I suppose we could also have
:
: for words {...}
: for tokens {...}
: for paragraphs {...}
: for chunks(, :delim(/^^===+\h*\n/)) {...}
:
: etc.
I see a problem with
for words {...}
since there's likely to be a words method on strings. Maybe we want:
for fwords {...}
Er...on second thought, we probably just have to write:
for words = {...}
or
for words(lines()) {...}
instead. And of course, tokens() is silly unless you have defined a lexer.
Which leaves paragraphs(), which is not really common enough to do as other
than a mod to the filehandle. So it comes back to lines/chunks/files.
Larry
Re: Arglist I/O [Was: Angle quotes and pointy brackets]
On Fri, Dec 03, 2004 at 06:43:05PM +, Herbert Snorrason wrote:
: This whole issue kind of makes me go 'ugh'. One of the things I like
: best about Perl is the amazing simplicity of the input construct.
Hmm.
while () {...}
for .lines {...}
Looks like a wash to me.
: Replacing that with something that not only is object oriented, but on
: top of that also LOOKS object oriented is bound to be a loss. It's
: going to be that bit longer to write, and not the least bit easier to
: understand.
Really? I dare you to show those two lines to any random
computer-literate but non-Perl-speaking stranger and see which one
they understand better.
And actually, .lines *wins* on keystrokes if you count shift keys.
: Neither the conceptual input operator nor the extremely
: handy idiom for behave like a Unixy filter should go. Please.
It's all cargo cult at that level anyway, so whether it looks OO or not
is really completely immaterial to its usability.
If .lines loses out, it won't be because of any of your arguments, but
because $*ARGS maybe shouldn't be the topic of Main. But $*ARGS is
most certainly an object of some sort, whether or not we hide that fact
from the cargo culters.
: If you don't like the angles doing it, by all means take them. But
: don't push that far into OO land. There's a reason we aren't all using
: Python and Ruby by now.
Sounds to me like you're just allergic to dots.
And I don't buy the nuclear blackmail argument either. I'll start
worrying about people switching to Python and Ruby when those languages
get a clue about how natural languages work. As far as I know, there's
little notion of topics in those languages as of yet. (Though I wouldn't
be surprised if other languages eventually adopt our invocantless .foo
notation. For the price of one character, we document exactly which
functions default to $_. In Perl 5 you just have to memorize the list.)
But as I say, I'm not yet convinced $*ARGS should be the topic.
It would only be the topic outside of the main loop, and people would
wonder why .lines gives them a different answer in another location.
That's the real problem with it. So you'll probably get your wish
of some non-OO-looking syntactic sugar. Might even just be a global
multi sub that defaults to $*ARGS:
multi sub *lines (IO ?$handle = $*ARGS) {...}
multi sub *lines (Str $filename) {...}
multi sub *lines (IO @handle) {...}
multi sub *lines (Str @filenames) {...}
Then the filter call would be quite hypoallergenic:
for lines {...}
Interestingly, though, you can also call it as $fh.lines if you like.
Or even if you don't.
Larry
