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: pull & put (Was: Angle quotes and pointy brackets)
On Mon, 06 Dec 2004 12:22:22 GMT, Smylers <[EMAIL PROTECTED]> wrote: David Green writes: I guess we could always use prepend/append, pull/pop. No! C and C are a well-defined pair, not just in Perl, for dealing with stacks; we should keep those as they are. (And no synonyms, before somebody suggests any!) Yeah. C and C are old and glorious ones (asm comes to mind), and C is too (even DOS .bat files used it, AFAIR), and it's a one of the most used perl5 CORE:: ops (it's more common than other three) .. And I like to shift :) the only doubtful word for me is unshift. Althought I would be pretty happy if we leave it as is, C is nice and short. but please don't swap meanings of old ops! if old push suddenly would try to unshift something, it could bring some perl5 programmers to hospital.
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 C 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: pull & put (Was: Angle quotes and pointy brackets)
On Mon, 6 Dec 2004 11:34:24 -0800, Larry Wall <[EMAIL PROTECTED]> wrote:
> Though it's awfully tempting to fill in the holes in the periodic table:
>
> ($a, $b, $c) = @foo *<< 3;
>
> And then just say all the corresponding unaries default to 1 (or the arity
> of the left):
>
> $bit = +<< $number; # $number +<< 1
> $graph = ~<< $string; # chip()/chimp()
> $whether = ?<< $boolean;# presumably clears $boolean
> $elem = *<< $iterator; # shift $iterator
Well, that's interesting.
> I suppose unary *>> would mean pop. Blurch. Let's stick with the binaries,
> if we add 'em at all. I do think
>
> foo( @bar *<< 3 )
> foo( @bar *>> 3 )
Hrm... if you're thinking of going that way, I'd rather have a
lazy-assignment/destructive-pipe operator of some sort:
($a,$b) <== [EMAIL PROTECTED]; # splice(@bar, 0, 2)
($a, $b) ==> [EMAIL PROTECTED] # splice(@bar, 0, 0, $a, $b)
[EMAIL PROTECTED] ==> ($a, $b); # splice(@bar, -2)
[EMAIL PROTECTED] <== ($a, $b); # splice(@bar, @bar, 0, $a, $b);
Of course, with something indicating the desire to modify the array. I
don't know that [EMAIL PROTECTED] would be right for that, but I dunno. Just an
idea.
I'd want some way of telling the array to lazily add/remove elements
as part of the pipe operator, which would make:
foo <== [EMAIL PROTECTED]; # REMOVE however many elements from the front of
@bar
as foo() wants
However, this would lead to me thinking about this sequence:
[EMAIL PROTECTED] ==> map ==> grep ==> @whatever;
as:
while pop @this { ... unshift @that, $_ }
Which would be interesting (bad) for performance
Ashley
Re: pull & put (Was: Angle quotes and pointy brackets)
stuff & grab :-) -- Mark Biggar [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] -- Original message -- > On Mon, Dec 06, 2004 at 10:45:22AM -0500, Austin Hastings wrote: > : But I'd be willing to rename them to get/put. > > If I went with "get", the opposite would be "unget" for both historical > and huffmaniacal reasons. > > Larry
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 C changes topic, then what?
OUTER::.:send_one($_);
Yuck.
=Austin
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: pull & put (Was: Angle quotes and pointy brackets)
On Mon, Dec 06, 2004 at 03:50:42PM -0500, Austin Hastings wrote:
: Larry Wall wrote:
:
: >On Mon, Dec 06, 2004 at 11:52:22AM -0700, Dan Brian wrote:
: >: >If I went with "get", the opposite would be "unget" for both historical
: >: >and huffmaniacal reasons.
: >
: >
: Why? (I get the huffman, not the history.) Is it just a nod to unshift?
Try "man ungetc".
: >Given the existence of a unary = for abbreviated use, I'd probably
: >stick with shift/unshift. (Presumably changing the semantics of
: >shift from p5 to be list/scalar/n-ary context sensitive, so you'd
: >have to write "scalar shift" to get Perl 5's shift semantics
: >in list context.)
: >
: >
: What about add/remove?
Backwards Huffman, considering removal happens more often.
: sub unshift(@a, [EMAIL PROTECTED])
: {
: @a.add(@items);
: }
:
: We could add :head and :tail, with :head the default, and let push|pop
: be equivalent to (add|remove).assuming(tail => 1)
"remove" is a transitive verb. I think people would take "remove"
to be "remove any occurrences of", and in the absence of any obvious
direct object, "remove this array", or "remove the list of files in
this array".
: As a side note, other than historical consistency, is there a good
: reason for push/pop to use the end of the array? I'd argue that for a
: stack, you only want to "know" one address: @stack[0] -- the 'top' of
: the stack -- and if you ever iterate a stack you're inclined to see the
: items in "distance-from-top" order, making 0..Inf the right array
: sequence. If we're going to reorg the function space, let's huffmanize
: the stack stuff (push/pop/0) and let the other stuff go hang.
For indexable arrays, the front is what you want to nail down, but
that means it's difficult to make unshift efficient. Swapping push/pop
for shift/unshift would make push/pop rather inefficient. And the top
of your stack can just as easily be @stack[-1] as it is now.
I don't see much reason to change what we have currently unless we
decided "shift" was too long, and it isn't if we have unary = for
interators, and real function args to take away most of "my $arg = shift;".
Appearances to the contrary notwithstanding, I'm not trying to break
Perl 5 constructs just for the heck of it.
Larry
Re: pull & put (Was: Angle quotes and pointy brackets)
Larry Wall wrote:
On Mon, Dec 06, 2004 at 11:52:22AM -0700, Dan Brian wrote:
: >If I went with "get", the opposite would be "unget" for both historical
: >and huffmaniacal reasons.
Why? (I get the huffman, not the history.) Is it just a nod to unshift?
Given the existence of a unary = for abbreviated use, I'd probably
stick with shift/unshift. (Presumably changing the semantics of
shift from p5 to be list/scalar/n-ary context sensitive, so you'd
have to write "scalar shift" to get Perl 5's shift semantics
in list context.)
What about add/remove?
sub unshift(@a, [EMAIL PROTECTED])
{
@a.add(@items);
}
We could add :head and :tail, with :head the default, and let push|pop
be equivalent to (add|remove).assuming(tail => 1)
As a side note, other than historical consistency, is there a good
reason for push/pop to use the end of the array? I'd argue that for a
stack, you only want to "know" one address: @stack[0] -- the 'top' of
the stack -- and if you ever iterate a stack you're inclined to see the
items in "distance-from-top" order, making 0..Inf the right array
sequence. If we're going to reorg the function space, let's huffmanize
the stack stuff (push/pop/0) and let the other stuff go hang.
=Austin
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: pull & put (Was: Angle quotes and pointy brackets)
On Mon, Dec 06, 2004 at 11:52:22AM -0700, Dan Brian wrote: : >If I went with "get", the opposite would be "unget" for both historical : >and huffmaniacal reasons. : : But "get" has too strong a class accessor connotation in most OO. : : "unpull?" ;-) Given the existence of a unary = for abbreviated use, I'd probably stick with shift/unshift. (Presumably changing the semantics of shift from p5 to be list/scalar/n-ary context sensitive, so you'd have to write "scalar shift" to get Perl 5's shift semantics in list context.) Though it's awfully tempting to fill in the holes in the periodic table: ($a, $b, $c) = @foo *<< 3; And then just say all the corresponding unaries default to 1 (or the arity of the left): $bit = +<< $number; # $number +<< 1 $graph = ~<< $string; # chip()/chimp() $whether = ?<< $boolean;# presumably clears $boolean $elem = *<< $iterator; # shift $iterator That would mean that we couldn't use those unaries in front of <<...>> though. I suppose unary *>> would mean pop. Blurch. Let's stick with the binaries, if we add 'em at all. I do think foo( @bar *<< 3 ) foo( @bar *>> 3 ) might actually be clearer than foo( splice(@bar,0,3) ) foo( splice(@bar,-3,3) ) Also, note that neither of the latter examples means the same as foo( pop(@bar,3) ) since pop would presumably pop them in reverse order from splice. We also get all the rotates if we allow *<<< and *>>>. On the other hand, if anyone suggests a list xor: @foo *^ @bar I'll ask whether they mean @foo »+^« @bar @foo »~^« @bar @foo »?^« @bar @foo »*^« @bar Larry
Re: pull & put (Was: Angle quotes and pointy brackets)
On Mon, Dec 06, 2004 at 01:25:29PM -0600, Rod Adams wrote: > Dan Brian wrote: > > >>If I went with "get", the opposite would be "unget" for both historical > >>and huffmaniacal reasons. > > > > > >But "get" has too strong a class accessor connotation in most OO. > > > >"unpull?" ;-) > > > > > pushf/popf. f is for "front". Ew! I'd prefer :head/:tail modifiers to push/pop over that. But ... > But I still don't see anything wrong with shift/unshift. Neither do I. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: pull & put (Was: Angle quotes and pointy brackets)
Dan Brian wrote: If I went with "get", the opposite would be "unget" for both historical and huffmaniacal reasons. But "get" has too strong a class accessor connotation in most OO. "unpull?" ;-) pushf/popf. f is for "front". But I still don't see anything wrong with shift/unshift. I'd prefer to avoid having a group of words that all mean about the same thing, but keeping them straight requires some memory trick. I program in too many languages to keep my mnemonics straight. There's going to be enough fun with is/has/does/but. For reference, I always have to do a 'perldoc perlvar' when I need a P5 $. -- Rod Adams
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 C in the examples in favor of C, 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 C statement is not an arbiter of lists.
Okie.
> In any event, I don't think C is ever going to provide an n-ary
> context to whatever it wants a boolean value from. That's what C
> is for.
Somehow I knew you were going to say that. I'm just being reluctant
to use C for something I've been using C for all this time.
-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 C in the examples in favor of C, 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 C 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 C is ever going to provide an n-ary
context to whatever it wants a boolean value from. That's what C
is for.
Larry
Re: pull & put (Was: Angle quotes and pointy brackets)
If I went with "get", the opposite would be "unget" for both historical and huffmaniacal reasons. But "get" has too strong a class accessor connotation in most OO. "unpull?" ;-)
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 C in the examples in favor of C, 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: 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: 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: pull & put (Was: Angle quotes and pointy brackets)
On Mon, Dec 06, 2004 at 10:45:22AM -0500, Austin Hastings wrote: : But I'd be willing to rename them to get/put. If I went with "get", the opposite would be "unget" for both historical and huffmaniacal reasons. 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
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 C suggests "start at the
: beginning, continue to the end". OTOH, using C 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 C in the examples in favor of C, 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
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 C:
:
: for .lines {...}
:
: but that sets the topic. I'm a little fuzzy on this, but doesn't C
: 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
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
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: pull & put (Was: Angle quotes and pointy brackets)
Smylers wrote: Larry Wall writes: But then are we willing to rename shift/unshift to pull/put? Yes. C is a terrible name; when teaching Perl I feel embarrassed on introducing it. No! But I'd be willing to rename them to get/put. 'Pull' is the opposite of 'push', but 'pop' already works. Given the nature of many of the other changes in Perl 6, completely changing regexps for example, renaming a couple of functions seems minor. Agreed. Smylers =Austin
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 C:
for .lines {...}
but that sets the topic. I'm a little fuzzy on this, but doesn't C
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 C suggests "start at the
beginning, continue to the end". OTOH, using C 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 C in the examples in favor of C, for a while? :)
=Austin
Re: pull & put (Was: Angle quotes and pointy brackets)
David Green writes: > I guess we could always use prepend/append, pull/pop. No! C and C are a well-defined pair, not just in Perl, for dealing with stacks; we should keep those as they are. (And no synonyms, before somebody suggests any!) Smylers
Re: pull & put (Was: Angle quotes and pointy brackets)
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Luke Palmer) wrote: >But what we'd really like to do is: given the user knows what push/pop >do, what would they *guess* to mean shift (I tend to think that this >is a very good technique for naming). >And, well, I'm thinking pull. So it's a toss-up between shift/unshift >and put/pull. I think "push" and "pull" fairly naturally could be taken to refer to the front of an array; you might even argue that the natural direction for something to "pop" is away from you (i.e. off the back) The problem I have with push/pull referring to opposite ends is that the same person is doing the pushing and the pulling, so both words ought to apply to the same end of the array (the front end), which violates the comp-sci-y expectations. (And although normally I'm happy to chuck CS jargon out the window, because so much of it is really bad, the push/pop thing goes pretty deep.) Not to mention everyone coming from Perl <6. Though if we had "push" without "pop", that wouldn't be as bad. I guess we could always use prepend/append, pull/pop. You might not guess what they meant, but once you know, I think the meanings are reasonably "obvious". (Dislike typing though I may, I'm hesitant to suggest "prep" and "app".) Hm, actually counting letters, "prepend" is no longer than "unshift" (and if not a real word, is at least used as one more often than "unshift" is). In fact, prepend/append/pull/pop altogether are only one letter more than push/pop/shift/unshift. So those are now officially my preferred replacements. But if we want something that makes it immediately obvious what end of the array we're messing with.. something visually obvious... ooh, this sounds like a job for Unicode!! (Just kidding. Sort of.) We've already got those lovely pipe operators to build on, and they can already do assignment; if you can go from = to +=, why not from <== to +<==? @a <== $foo, $bar; # @a=($foo, $bar) $foo, $bar ==> @a; # ditto @a +<== $foo, $bar; # push @a, $foo, $bar $foo, $bar ==>+ @a; # unshift @a, $foo, $bar @a -==> $foo, $bar; # ($bar, $foo) = (pop @a, pop @a) $foo, $bar <==- @a; # ($foo, $bar) = (shift @a, shift @a) The + or - tells you whether you're adding on or taking away, and the arrow points to (or from) the end of the array you're doing it to. (I know some people will hate four symbols in a row. That's why we have seven-letter alternatives like "prepend".) I was going to say an advantage over old-fashioned pop/shift is that you could remove more than one element at a time, but there isn't any reason for their P6 versions not to return as many items as are want()ed, is there? The bad news (assuming anyone actually thinks there's anything good in the above suggestion) is that since +<== and friends are assignment operators, you can't just do foobar( @a-==>, $x, $y). Um, unless -==> could be made to work as a unary operator. Which even I don't think I like. =) So we should keep the wordy versions too. -David "pull goes the weasel" Green
Re: iteration (was Re: Angle quotes and pointy brackets)
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Matt Diephouse) wrote: >On Sat, 04 Dec 2004 08:59:24 -0700, David Green <[EMAIL PROTECTED]> wrote: >C signifies a role named "Iterate". Roles are sort of a >mix of interfaces and mixins (as I understand it -- I'm still waiting >for E12). So saying a class fulfills a role just means that it >provides certain methods. In this case, I was saying class with the >Iterate role would provide a C<.next> method. I thought of that at first, but I don't want to have to call my iterating method "next" any more than I want to *have* to call my constructor "new". But there is a difference in that "new" is called by some user who is supposed to have read the documentation, whereas "next" needs to get implicitly called by "for". So maybe it really should be a Role. (One can always provide methods with better names that simply call the "real" .next, .prev, .final, etc. for increased user-friendliness.) &eof := &final;# is that how to create an alias for a sub/method? > >We've got "while" for looping, ".next" for iterating, > > and "for" for doing both in one convenient little shortcut. > >But for needs to know if it has an iterator or a list. You don't want >it iterating over things you didn't want it iterating. In this case, I >was suggesting making an, though I suppose something like >C<$sth.execute> could just return one. Well, I was looking at lists as being kinds of iterators. If you want to "for" over an iterator without actually iterating it, I guess you'd have to make a reference to it or put it inside a list (so the list would be iterated instead). - David "iterate: to go around and around, like my head" Green
Re: pull & put (Was: Angle quotes and pointy brackets)
It makes good sense to me -- if we're trying to move a piano from you to me then either you can push or your end or I can pull on my end: we're operating on different ends of it, but the effect in both cases is moving in one direction. As a mnemonic for remembering which side push/pull operate on, I agree. (A stalled car etc.) It would be nice if the corresponding functions could similarly be opposed without the potential confusion for beginners, but I realize that may not be possible, and your example is at least convincing that it's better than shift/unshift.
Re: pull & put (Was: Angle quotes and pointy brackets)
Dan Brian writes: > Having push and pull operate on opposite ends of an array strikes me > as more confusing than even shift. It makes good sense to me -- if we're trying to move a piano from you to me then either you can push or your end or I can pull on my end: we're operating on different ends of it, but the effect in both cases is moving in one direction. Now instead of a piano imagine one of those conveyor belts that you get at supermarket checkouts: you push your goods on one-end, and the cashier pulls them off the other. When the cashier pulls one item off that unbreaks the light beam to the sensor, which triggers the motor, and all the other items get pulled along too, moving one place along. Smylers
Re: pull & put (Was: Angle quotes and pointy brackets)
If there's a willingness to rename shift/unshift, why not consider going a bit further (and offend shell heritage) to note that pull/put aren't really linguistically opposed either (unlike push/pull). Why not rename pop to pull, and use something like put/take for shift/unshift? That goes way beyond offending "shell heritage". That actively opposes sixty years of computer science terminology setting "push" and "pop" in opposition. I'm not objecting to pop, but pull in opposition to push, on the other side of the array.
Re: Angle quotes and pointy brackets
On Thursday, December 2, 2004, 10:08:31 AM, you (mailto:[EMAIL PROTECTED]) wrote: > On Tue, 30 Nov 2004, Austin Hastings wrote: >> How about just having C< system() > return a clever object with .output and >> .err methods? > interesting... > Michele Prior art of this on Windows... http://msdn.microsoft.com/library/en-us/script56/html/wslrfExecMethod.asp (the respective properties on the returned WshScriptExec instance being .StdOut and .StdErr.) -- Richard mailto:[EMAIL PROTECTED]
Re: pull & put (Was: Angle quotes and pointy brackets)
Dan Brian writes: > If there's a willingness to rename shift/unshift, why not consider > going a bit further (and offend shell heritage) to note that pull/put > aren't really linguistically opposed either (unlike push/pull). Why not > rename pop to pull, and use something like put/take for shift/unshift? > Having push and pull operate on opposite ends of an array strikes me as > more confusing than even shift. When it comes to adding and removing > elements, shouldn't there be semantic opposition for functions that > operate on the same end? I don't think that's a good time. It kills the array-as-stack idiom, which, well, everybody uses all the time. I don't mind the linguistic nonopposition of pull/put. The main thing I don't like is the alliteration between push/pop. That makes for very difficult mnemonics. Obviously, the CS-literate can just remember that they're the nonstack ops, but many Perlers are Shellers and Adminers, without being CSers. I've actually been happy with shift/unshift. But what we'd really like to do is: given the user knows what push/pop do, what would they *guess* to mean shift (I tend to think that this is a very good technique for naming). And, well, I'm thinking pull. So it's a toss-up between shift/unshift and put/pull. Luke
Re: pull & put (Was: Angle quotes and pointy brackets)
On Sat, 4 Dec 2004 23:33:24 -0700, Dan Brian <[EMAIL PROTECTED]> wrote: > If there's a willingness to rename shift/unshift, why not consider > going a bit further (and offend shell heritage) to note that pull/put > aren't really linguistically opposed either (unlike push/pull). Why not > rename pop to pull, and use something like put/take for shift/unshift? That goes way beyond offending "shell heritage". That actively opposes sixty years of computer science terminology setting "push" and "pop" in opposition. (Well, maybe not *sixty* years, but you get the idea.) -- Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> Perl and Parrot hacker "I might be an idiot, but not a stupid one." --c.l.p.misc (name omitted to protect the foolish)
Re: pull & put (Was: Angle quotes and pointy brackets)
C's only virtue, IMHO, is that it's clearly the inverse of C. But I think the spelling and aural relationship between C, C, C, and C is clear enough to negate that. But then, I'm a little biased. Except that push and pull are logical opposites linguistically, but not in standard CS parlance. could be very confusing. There's a possibility of using C and C for enqueue/dequeue, except that C == C in standard implementations. So C and C? yeck. If there's a willingness to rename shift/unshift, why not consider going a bit further (and offend shell heritage) to note that pull/put aren't really linguistically opposed either (unlike push/pull). Why not rename pop to pull, and use something like put/take for shift/unshift? Having push and pull operate on opposite ends of an array strikes me as more confusing than even shift. When it comes to adding and removing elements, shouldn't there be semantic opposition for functions that operate on the same end? (I realize that take is already ... taken, for control structures.)
Re: pull & put (Was: Angle quotes and pointy brackets)
Brent 'Dax' Royal-Gordon wrote: Smylers <[EMAIL PROTECTED]> wrote: Yes. C is a terrible name; when teaching Perl I feel embarrassed on introducing it. C's only virtue, IMHO, is that it's clearly the inverse of C. But I think the spelling and aural relationship between C, C, C, and C is clear enough to negate that. But then, I'm a little biased. Except that push and pull are logical opposites linguistically, but not in standard CS parlance. could be very confusing. There's a possibility of using C and C for enqueue/dequeue, except that C == C in standard implementations. So C and C? yeck. -- Rod Adams
Re: pull & put (Was: Angle quotes and pointy brackets)
Smylers <[EMAIL PROTECTED]> wrote: > Yes. C is a terrible name; when teaching Perl I feel > embarrassed on introducing it. C's only virtue, IMHO, is that it's clearly the inverse of C. But I think the spelling and aural relationship between C, C, C, and C is clear enough to negate that. But then, I'm a little biased. -- Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> Perl and Parrot hacker "I might be an idiot, but not a stupid one." --c.l.p.misc (name omitted to protect the foolish)
Re: iteration (was Re: Angle quotes and pointy brackets)
David Green <[EMAIL PROTECTED]> wrote: > Aren't lazy lists a funny kind of iterator? Ones that memoise their > results. And supply an indexing method []. As I mentioned the other day, I fail to see any material difference between an iterator and a lazy list, except that a few operations are allowed on a lazy list that aren't on an iterator. (And all of those could be emulated, albeit inefficiently, with one; even with a pipe, if the user does $pipe[1024], there's no technical reason you can't store the first thousand-odd lines and return the one they asked for.) Also note that there's no difference between iterating over a lazy copy of an array, and iterating over a lazy copy of a lazy copy of an array, except for the amount of indirection; thus, there would be no need for for() to distinguish between C and C (though both of those forms might need a splat). -- Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> Perl and Parrot hacker "I might be an idiot, but not a stupid one." --c.l.p.misc (name omitted to protect the foolish)
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 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 11:02:38PM +0300, Alexey Trofimenko wrote:
: hm. we have short and strange , 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 {...}
: # or
: for files {...}
: # 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 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
:by adverb. And perhaps that also turns on autochomping.
Larry
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, 04 Dec 2004 11:03:03 -0600, Rod Adams <[EMAIL PROTECTED]> wrote:
Larry Wall wrote:
for =$*IN {...}
for =$*ARGS {...}
for = {...}
for = {...}
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 , 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 {...}
# or
for files {...}
# 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 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]
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 %hÂkeyÂ
$a < $b with %h
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]
Larry Wall wrote:
So you can say
for =$*IN {...}
for =$*ARGS {...}
for = {...}
for = {...}
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 == {...}
for == {...}
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]
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 , 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 = =;
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: iteration (was Re: Angle quotes and pointy brackets)
On Sat, 04 Dec 2004 08:59:24 -0700, David Green <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Matt Diephouse) wrote:
> >Supposing
> >class Filehandle does Iterate; # Iterate or Iterator?
> >we have an easy way to create new iterators. I'm not sure how useful
> >they would be in Perl 6
>
> Maybe the class doesn't do it, but one of its methods does? Then you
> can call it whatever makes sense.
C signifies a role named "Iterate". Roles are sort of a
mix of interfaces and mixins (as I understand it -- I'm still waiting
for E12). So saying a class fulfills a role just means that it
provides certain methods. In this case, I was saying class with the
Iterate role would provide a C<.next> method.
> >Which be even cuter like this (I think):
> >for iter($sth.execute) -> $results { ... }
> >where iter creates an Iterator object that just knows to call C<.next>
> >on its argument.
>
> That still seems too cumbersome to me. Isn't it "for" that knows to
> call .next (or .sequel, whatever)? I'm thinking that that is the
> point of "for $foo", which should be approximately the same as "while
> $foo.next". We've got "while" for looping, ".next" for iterating,
> and "for" for doing both in one convenient little shortcut.
But for needs to know if it has an iterator or a list. You don't want
it iterating over things you didn't want it iterating. In this case, I
was suggesting making an, though I suppose something like
C<$sth.execute> could just return one.
> >Hoping I haven't removed all doubt of my foolishness,
>
> I'm hoping this reply reassures you.
Thanks.
--
matt diephouse
http://matt.diephouse.com
Re: iteration (was Re: Angle quotes and pointy brackets)
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Matt Diephouse) wrote:
>What I mean is that Perl takes an array and makes an iterator out of it.
>Sure, you probably don't think about it like that, but the behavior is
>the same (who says arrays need to iterate starting at element zero?).
I probably didn't, but over the last couple of days I've been thinking
about it like that more and more.
>The odd thing is that here we are designing Perl 6, and we're trying
>to take an iterator and make it into an array so that we can turn it
>back into an iterator again. It seems like we should just use it as an
>iterator::
>for $iterator -> $elem { ... }
Yes!
>Supposing
>class Filehandle does Iterate; # Iterate or Iterator?
>we have an easy way to create new iterators. I'm not sure how useful
>they would be in Perl 6
Maybe the class doesn't do it, but one of its methods does? Then you
can call it whatever makes sense.
class Filehandle
{ method next is iterator {...} }
class Monarch
{ method succeed is iterator {} }
class Blockbuster
{ method sequel is iterator { $.title++; return $self; } }
>(how do iterators compare to lazy lists?)
Aren't lazy lists a funny kind of iterator? Ones that memoise their
results. And supply an indexing method [].
>Which be even cuter like this (I think):
>for iter($sth.execute) -> $results { ... }
>where iter creates an Iterator object that just knows to call C<.next>
>on its argument.
That still seems too cumbersome to me. Isn't it "for" that knows to
call .next (or .sequel, whatever)? I'm thinking that that is the
point of "for $foo", which should be approximately the same as "while
$foo.next". We've got "while" for looping, ".next" for iterating,
and "for" for doing both in one convenient little shortcut.
So lists and arrays would be iterators, although they may not flaunt it
in public. But you could always explicitly call their .next method if
you wanted to. For example,
for @lines
{
if s/\\$// # ends with a backslash = continued on next line
{
$_ ~= @lines.next;
redo;
}
# now process our joined line ...
}
Of course, that's just the example for "redo" from the Camel, except
using an array instead of <>. A P5 array wouldn't have worked, because
there's no way to get the "next" iteration of an array in the way that
you can use a scalar <> to read the next line of the file. (Though
there ought to be a better way of referring to the object of the "for"
-- I had to refer to it by name here, but I couldn't do that if it were
a list; and $_ is already taken. @_ strikes me as reasonable (for a
not necessarily very large value of "reasonable").)
I'm not sure how much extra syntax is needed. Something that's
expected to iterate (like a filehandle) should just iterate naturally
when used in scalar context, or list context, or both. (But a
filehandle might stringify to the filename in string context, and
return the filehandle object itself when being passed to a function
looking for a filehandle.)
Something that isn't typically expected to iterate (like an array)
could use its .next method, which is a tad wordy, but that's good
because that makes it clear and obvious that we are explicitly
iterating.
Presumably you could slurp up all the iterations at once using * or
** to flatten them. That still doesn't get us the magical <> because
it's really a double iteration (over the filenames in @ARGS and then
over the contents of each file). In fact, that's just a specific case
of wanting to loop through several iterators -- C only loops through the *list* of iterators, not through
each object itself.
So maybe we do need Larry's new [EMAIL PROTECTED] to get that kind of
double-iteration (without having to nest "for" loops, ugh!). Hm.
Unless the flattening operator will take care of that. C would do it, but I'm not sure about
C. (It would definitely do *something*, of that
I'm fairly confident!)
But I'm starting to think I may have just been thinking the original
problem all along, only inside-out
>Hoping I haven't removed all doubt of my foolishness,
I'm hoping this reply reassures you.
- David "at risk of removing all doubts of mine" Green
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]
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 = {...}
for = {...}
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 = =;
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 =;
And I don't think it'll be visually confusing to people who put spaces
on both sides of their assignment operators.
Larry
Re: pull & put (Was: Angle quotes and pointy brackets)
Larry Wall writes: > But then are we willing to rename shift/unshift to pull/put? Yes. C is a terrible name; when teaching Perl I feel embarrassed on introducing it. Given the nature of many of the other changes in Perl 6, completely changing regexps for example, renaming a couple of functions seems minor. Smylers
Re: Angle quotes and pointy brackets
On Tue, 30 Nov 2004 14:58:13 -0800, Larry Wall <[EMAIL PROTECTED]> wrote:
> But then it's not a general iterator iterator. Plus it has the Unicode
> taint...
>
> Back to reality, another thought to weave in here is that something
> like
>
> for $iterator.each -> $x {...}
>
> might specify that there may be ordering dependencies from loop
> iteration to loop iteration, whereas (since junctions are inherently
> unordered) saying:
>
> for $iterator.all -> $x {...}
>
> explicitly tells the system it can parallelize the loop without worrying
> about interation between iterations.
I've been thinking about it, and this strikes me as really odd. Perl 5
is full of nice shortcuts. One of them is:
for (@array) {
which takes the place of
for (my $i = 0; $i < @array; $i++) {
which is what you'd have to do in a lot of other languages. What I
mean is that Perl takes an array and makes an iterator out of it.
Sure, you probably don't think about it like that, but the behavior is
the same (who says arrays need to iterate starting at element zero?).
Java just introduced something similar in 1.5.
The odd thing is that here we are designing Perl 6, and we're trying
to take an iterator and make it into an array so that we can turn it
back into an iterator again. It seems like we should just use it as an
iterator::
for $iterator -> $elem { ... }
Your message leads me to believe that
for all(1, 2, 3) -> $num { ... }
is already a special case that will or can be recognized and
optimized. If so, having special behavior for an iterator shouldn't be
much more difficult (though I'm not sure of the correctness or full
ramifications of this statement).
That would have the added benefit of letting me write this:
for open($filename) or die -> $line { ... }
which I like. A method could be used for retrieving the next
line/char/byte/whatever:
my $fh = open $filename or die;
my $line = $fh.next
where C<.next> splits on the input record separator. C<.next_byte> and
family could be implemented on top of that as well.
The biggest problem I see (and I may just be blind) is that
for $iterator -> $x { ... }
is slightly ambiguous to the programmer, which makes me want angle
brackets back. Other syntax could be used (though we seem to be
drawing a blank there), but I don't like the idea of using a method
(see Iterator->Array->Iterator above).
I also like the idea of general iterators. Really like it. Perl 5 had
it via C, but it wasn't so pretty. Supposing
class Filehandle does Iterate; # Iterate or Iterator?
we have an easy way to create new iterators. I'm not sure how useful
they would be in Perl 6 (how do iterators compare to lazy lists?), but
I can see if being useful.
For instance, perhaps a more idiomatic DBI could be written like this:
my $sth = $dbh.prepare('SELECT * FROM foo');
for $sth.execute.iter -> $results { ... }
Which be even cuter like this (I think):
for iter($sth.execute) -> $results { ... }
where iter creates an Iterator object that just knows to call C<.next>
on its argument.
Anyway, take it for what its worth. I'm aware of how ridiculous many
of the things we (that includes me) say are, but perhaps I've said
something useful.
Hoping I haven't removed all doubt of my foolishness,
--
matt diephouse
http://matt.diephouse.com
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
Re: Arglist I/O [Was: Angle quotes and pointy brackets]
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. 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. Neither the conceptual "input operator" nor the extremely handy idiom for "behave like a Unixy filter" should go. Please. 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. -- Schwäche zeigen heißt verlieren; härte heißt regieren. - "Glas und Tränen", Megaherz
Arglist I/O [Was: Angle quotes and pointy brackets]
On Fri, Dec 03, 2004 at 09:31:33AM -0800, Larry Wall wrote:
: I guess the only real argument against unifying is that neither of
:
: for [EMAIL PROTECTED] {...}
:
: or
:
: for @foo {...}
:
: indicate destructive readout. Which probably says that *
: is the wrong operator to use for that, which undoes our pretty
:
: for * {...}
This is all muddled thinking anyway, since [EMAIL PROTECTED] would read the
arguments,
not the lines from the files contained in the arguments. Despite the
history of ARGV in Perl 5, I wonder if it's a mistake to overload @ARGS
and $ARGS to mean two different things.
On the other hand, it'd be nice if we could end up with something
readable like:
for .lines {...}
where the implicit invocant of Main knows how to iterate magically through
the lines of @ARGS. I suppose that implicit invocant could be named $ARGS.
The magic still consists of making a bunch of filenames look like a single
filehandle. A method like .lines could work either on a filehandle, or
on a string representing a filename, or an array of filehandles, or an
array of strings representing filenames.
We also potentially get things like
for .slurp {...}
for .paragraphs {...}
But we have to be careful with things like
for "foo".bytes {...}
since "foo".bytes returns 3, not the bytes of file "foo". So there
needs to be some intermediate method to say that you mean io. Taking a
page fro IO::All, I suppose we could have "foo".io.bytes or some such.
But $ARGS would already be an io object, so people presumably wouldn't
have to always say
for .io.lines {...}
As I've said before, I like the idea of IO:All, except for the
overloading of < and >. Perhaps we could go with <== and ==> instead.
Larry
Re: Angle quotes and pointy brackets
On Fri, Dec 03, 2004 at 12:56:18AM -0800, Brent 'Dax' Royal-Gordon wrote:
: Larry Wall <[EMAIL PROTECTED]> wrote:
: > Speaking of "at the moment", I just now updated the Synopses at
: > dev.perl.org.
:
: The new S2 says:
: # Heredocs are no longer written with <<, but with an adverb on any other
: # quote construct:
: #
: # print qq:to/END/
: # Give $amount to the man behind curtain number $curtain.
: # END
:
: Does "any other quote construct" include rx//? I've wanted that for a
: while in Perl 5 (although with anonymous rules, I suppose it's no
: longer that important...).
The rx// construct is not an official quote construct because it
doesn't produce a string via run-time interpolation. But that doesn't
mean you shouldn't get access to :to somehow or other. Either we
hack it into the rx adverbs, or maybe we allow a backdoor into q//
via some kind of :rx adverb. Especially with the extended syntax
being the default, putting your rule over several heredocish lines
seems like a real win.
But we should probably look at the respective adverbs for q and rx to
see if we're setting up any awful cognitive dissonances. I confess I
haven't thought about that yet.
: # In order to interpolate an entire hash, it's necessary to subscript with
: # empty braces or angles:
: #
: #print "The associations are:\n%bar{}"
: #print "The associations are:\n%bar<>"
:
: Am I to assume you can use empty French/Texas quotes, too? (i.e.
: %bar«» or %bar<<>>).
Yes.
: This paragraph also made me realize: am I the only one who foresees
: somebody doing this?
:
: $OUT.printf("We produced %d somoflanges this month!\n", $content);
:
: (Granted, the fix is trivial--just replace the double-quotes with
: single-quotes, or add some of that optional spacing HTML lets you
: splatter around--but it seems like an easy mistake to make.)
Probably also a fairly easy mistake to catch if we discourage slash as the
first character inside a <...>. So maybe they'd get a warning unless they
wrote < /b > instead. Or maybe even an outright compilation error.
But there's no doubt that there will be occasional interference between *ML
and <> subscripts.
: Finally, I noticed that the "Files" section only talks about iterating
: over all lines. Do you have a decision on single-line reads yet?
Nope, though C is cute. But we still have this fundamental
underlying question of how much we want to unify array and iterator
notation that hasn't really been resolved. It seems a shame to set
up arrays with all these queue-like operations and then not use that
to describe, for instance, gather/take queues, or other inter-thread
message queues. So what if .[] isn't implemented, or is slow?
If you only ever shift/pull an array, does it matter? And really,
the essence of arrays is ordering: the indexability is only a side
effect of that.
But then are we willing to rename shift/unshift to pull/put? If we're
gonna go that far, we might as well switch all the bracket characters
around. Oh, wait...
I suppose it might be argued that if we present a queue as an array,
someone will index it instead of shifting it, and end up storing the
whole history of the queue in memory. Seems like a weak argument,
though. We already have that problem with arrays bound to infinite
generators.
I guess the only real argument against unifying is that neither of
for [EMAIL PROTECTED] {...}
or
for @foo {...}
indicate destructive readout. Which probably says that *
is the wrong operator to use for that, which undoes our pretty
for * {...}
But "for pull" doesn't read very well. Unfortunately we don't have any
destructive "all" quantifiers in English that I can think of offhand.
I suppose "every" comes about as close as anything.
Well, hey, if we have +<< meaning numeric left shift, how about
for @foo *<< 1 {...}
meaning list left shift? :-) * .999
: [And a note to the editors of dev.perl.org: can we get tables of
: contents on these documents? While it's nice to exercise Firefox's
: slick find-in-page interface so much on, say, Apocalypse 12, it'd be
: more convenient to just have a TOC.]
I miss 'em too, but they're admittedly ugly. Maybe they could be put
at the end, with a TOC link at the front?
Larry
Re: Angle quotes and pointy brackets
Larry Wall <[EMAIL PROTECTED]> wrote:
> Speaking of "at the moment", I just now updated the Synopses at
> dev.perl.org.
The new S2 says:
# Heredocs are no longer written with <<, but with an adverb on any other
# quote construct:
#
# print qq:to/END/
# Give $amount to the man behind curtain number $curtain.
# END
Does "any other quote construct" include rx//? I've wanted that for a
while in Perl 5 (although with anonymous rules, I suppose it's no
longer that important...).
# In order to interpolate an entire hash, it's necessary to subscript with
# empty braces or angles:
#
#print "The associations are:\n%bar{}"
#print "The associations are:\n%bar<>"
Am I to assume you can use empty French/Texas quotes, too? (i.e.
%bar«» or %bar<<>>).
This paragraph also made me realize: am I the only one who foresees
somebody doing this?
$OUT.printf("We produced %d somoflanges this month!\n", $content);
(Granted, the fix is trivial--just replace the double-quotes with
single-quotes, or add some of that optional spacing HTML lets you
splatter around--but it seems like an easy mistake to make.)
Finally, I noticed that the "Files" section only talks about iterating
over all lines. Do you have a decision on single-line reads yet?
[And a note to the editors of dev.perl.org: can we get tables of
contents on these documents? While it's nice to exercise Firefox's
slick find-in-page interface so much on, say, Apocalypse 12, it'd be
more convenient to just have a TOC.]
--
Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]>
Perl and Parrot hacker
"I might be an idiot, but not a stupid one."
--c.l.p.misc (name omitted to protect the foolish)
Re: Angle quotes and pointy brackets
On Thu, Dec 02, 2004 at 09:15:50PM -0800, Larry Wall wrote:
: On Thu, Dec 02, 2004 at 02:54:42PM -0700, John Williams wrote:
: : Does / <-> / capture to $0{'-'} ?
: : Or should that be written / <-«alpha»> / ?
:
: At the moment I've got it that only assertions of the form capture.
Which is a bit odd, insofar as gets captured by that rule...
Speaking of "at the moment", I just now updated the Synopses at
dev.perl.org. The juiciest new bits are probably in S2, though there
are ramifications in any Synopsis marked as having been updated Dec 2.
Anonymous enums are kinda cool now:
%mo = enum «:Jan(1) Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec»;
(The Apocalypses aren't updated yet. Tomorrow maybe, unless I get sucked
back into my little pet p5-to-p6 translator project.)
Larry
Re: Angle quotes and pointy brackets
On Thu, Dec 02, 2004 at 02:54:42PM -0700, John Williams wrote:
: Does / <-> / capture to $0{'-'} ?
: Or should that be written / <-«alpha»> / ?
At the moment I've got it that only assertions of the form capture.
Anything else you have to do an explicit binding, or use :keepall.
Larry
Re: Angle quotes and pointy brackets
John Williams writes:
> Is all the "Extensible metasyntax (<...>)" being changed to Â... ?
>
> Or is the new rule that <...> is capturing metasyntax, and Â... is
> non-capturing metasyntax?
That's the one.
> You can't really capture anything on an assertion, so
> /^foo .* <( do { say "Got here!" } or 1 )> .* bar$/
> is probably not an issue at all.
>
> How are the results different between these?
>
> //
Puts 's match object in $ (of the current match object).
> /()/
Puts 's match object in $ and its text in $1.
> /(ÂidentÂ)/
Puts the text captured by Âident into $1.
Luke
Re: Angle quotes and pointy brackets
On Tue, 30 Nov 2004, Larry Wall wrote:
> Here's the proposal.
>
> First the bad news:
> * We accept that the C<< < >> operator requires whitespace
> around it, and be prepared to be burned in effigy occasionally.
My biggest worry about this is that people will be writing
if $x<3
loop( $x=0 ; $x<10 ; $x++ )
more than occasionally.
> * We steal angles away from iterators.
I vote we do that in any case.
> Now, that has certain interesting outcomes.
>
> * We get <...> as the qw// shorthand where a term is expected.
>
> * Most uses of qw// involve strings and lists, so there's little
> visual interference with numeric comparison operators.
>
> * We get the cute, clean and rather more typeable
>
> $var[3]
I'm starting to like $var{'key1'}{'key2'}[3]{'key3'} more and more.
And it's the only way to write $var{'key with spaces'}, right?
> * That means that, roughly, we have this proportion:
>
> '...' : "..." :: <...> : «...»
That's definitely worth a cuteness award.
> Now with those out of the way, the good news:
> * All other uses of «...» and <...> swap, pretty much.
Moving this to the end, because I want to request clarification in the
context of rules.
> * Match vars become $ instead of $«foo».
>
> * A rule like now captures, while «ws» or <> doesn't.
Is all the "Extensible metasyntax (<...>)" being changed to «...» ?
Or is the new rule that <...> is capturing metasyntax, and «...» is
non-capturing metasyntax?
Does / <-> / capture to $0{'-'} ?
Or should that be written / <-«alpha»> / ?
You can't really capture anything on an assertion, so
/^foo .* <( do { say "Got here!" } or 1 )> .* bar$/
is probably not an issue at all.
How are the results different between these?
//
/()/
/(«ident»)/
~ John Williams
Re: Angle quotes and pointy brackets
On Tue, 30 Nov 2004, Austin Hastings wrote: How about just having C< system() > return a clever object with .output and .err methods? interesting... Michele -- Windows shuts down automaticaly giving an count down. what could be the problem Windows? - "Le TeXnicien de surface" in comp.text.tex
Re: Angle quotes and pointy brackets
On Tue, 30 Nov 2004, Brent 'Dax' Royal-Gordon wrote: I like this in general. However... Larry Wall <[EMAIL PROTECTED]> wrote: * Since we already stole angles from iterators, «$fh» is not how you make iterators iterate. Instead we use $fh.fetch (or whatever) in scalar context, and $fh.fetch or @$fh or $fh[] or *$fh in list context. I believe you tried this one a couple years ago, and people freaked out. As an alternative, could we get a different operator for this? [snip] Any other suggestions, people? I think I will miss angles... well, at least for some time. Of the proposal above I like best @$fh, since it's the one that most conveys the idea of syntactic sugar for iteration while still being fundamentally intuitive. Michele -- Se, nella notte in cui concepi' il duce, Donna Rosa, toccata da divina luce, avesse dato al fabbro predappiano invece della fica il deretano, l'avrebbe presa in culo quella sera Rosa sola e non l'Italia intera. - Poesia antifascista
Re: Angle quotes and pointy brackets
Larry Wall <[EMAIL PROTECTED]> writes:
> On Tue, Nov 30, 2004 at 03:03:38PM -0800, Jon Ericson wrote:
> : while(<>) {...}
> You left out the most important phrase:
>
> "or whatever we decide is the correctest idiom."
I saw that, but I didn't know what to make of it. The Perl 5 idiom is
pretty magic and I don't know if it's correcter to make it more or
less explicit:
for *$ARGV {...}
Only I wonder if the magic handle should be called $INPUT or
something.
> So if, as has been pointed out, @$handle is too much role shear, then we
> probably go with something like
>
> for *$handle {...}
>
> in which case, if there's no handle, it seems to degrade to
>
> for * {...}
>
> which seems amazingly something or other.
Lovely? But I'm afraid of extra typing. ;-) It looks like the shell
idiom:
for f in *; do ...; done
Jon
Re: Angle quotes and pointy brackets
On Wed, Dec 01, 2004 at 09:55:32AM +, Matthew Walton wrote: : >I neglected to mention that the smart quoter should also recognize : >pair notation and handle it. : : I've been trying to get my brain round that, but I can't quite figure : out what you mean. Pair notation is, as I understand it, when you get : : key => value : : to construct a pair. Assuming that's me remembering correctly, then : where does the smart quoter have to deal with pair notation? Are you : considering allowing something like: : : « key1 => flop key2 => floop » : : Which would be : : hash(key1 => flop, key2 => floop); : : or am I completely off my rocker? I hope I am, because that's kind of : ugly. Yes, that's the sort of thing I mean. I actually want it for enum defs: my Scalar enum hex « :zero(0) one two three four five six seven eight nine :ten eleven twelve thirteen fourteen fifteen »; : As an aside, is it possible for us to define our own autoquoting : operators? I assume it will be, but I'm feeling insecure and need : reassurance. You can replace the whole darn grammar if you like, so it's certainly possible. I don't think we'll go out of our way to make it easy though. Probably requires a lookahead on the identifier rule to see if the next thing happens to be a => workalike. Alternately, you have to do syntax tree munging with an infix macro, since by the time you see an infix macro its left argument is already parsed. Larry
Re: Angle quotes and pointy brackets
On Wed, 01 Dec 2004 07:41:18 GMT, Smylers <[EMAIL PROTECTED]> wrote:
> John Siracusa writes:
>
> > Call me crazy, but at this point I'm prone to stick with what I've done in
> > Perl 5 for years:
> >
> > $var{'key1'}{'key2'}[3]{'key3'}
>
> In which case do that, since it'll still work in Perl 6.
> [...]
> So life is better for people who like writing hash subscripts as you do.
> But for those who like autoquoting, there's now a different syntax, one
> that doesn't interfere with the above syntax at all. You don't have to
> use it if you don't want to, and everybody's happy!
Even if I don't use it, I'd like it not to be ugly and awkward (or, heaven
forbid, non-ASCII) because I'm likely to have to read and edit it a lot
(just as I have to deal with a lot $of{this} these days...sigh)
Although I like the single/double angle swap in most places, I'm definitely
not a fan of the "fragile fish chain" syntax for hash keys.
-John
Re: Angle quotes and pointy brackets
Matthew Walton writes: > Pair notation is, as I understand it, when you get > > key => value That can now also be written as: :key or, where value is 1, simply as: :key I suspect it was this form that Larry was referring to. Smylers
Re: Angle quotes and pointy brackets
Matthew Walton skribis 2004-12-01 10:11 (+): > Well that depends... are you intending to write programs, or drive the > world insane? Yes. Juerd
Re: Angle quotes and pointy brackets
Juerd wrote:
Matthew Walton skribis 2004-12-01 9:55 (+):
Yes, that would be fun... almost worth throwing out a compiler warning
for that, especially if we've still got use warnings. Something like
Warning: «{ }» creates empty list
It should generate a warning similar to the warning of interpolating an
undefined value, but with s/undefined variable/empty list/.
Yes, that would make sense.
Because I'm sure it should be wrong to create empty circumfix operators.
You have to admit that zero width circumfix operators would be VERY NEAT.
Well that depends... are you intending to write programs, or drive the
world insane?
Re: Angle quotes and pointy brackets
Matthew Walton skribis 2004-12-01 9:55 (+):
> Yes, that would be fun... almost worth throwing out a compiler warning
> for that, especially if we've still got use warnings. Something like
>
> Warning: «{ }» creates empty list
It should generate a warning similar to the warning of interpolating an
undefined value, but with s/undefined variable/empty list/.
> Because I'm sure it should be wrong to create empty circumfix operators.
You have to admit that zero width circumfix operators would be VERY NEAT.
Juerd
Re: Angle quotes and pointy brackets
Larry Wall wrote:
I thought so.
: I don't think I've ever used a hash slice in my life. Is there something
: wrong with me?
No, a lot of people are naturally monoindexous.
I like that word.
: >* The :w splitting happens after interpolation. So
: >
: > « foo $bar @baz »
: >
: > can end up with lots of words, while
: >
: > « foo "$bar" "@baz" »
: >
: > is guaranteed to end up with three "words".
:
: See the comment about 'fabulouser' above and add another 'and
: fabulouser' to the end.
I neglected to mention that the smart quoter should also recognize
pair notation and handle it.
I've been trying to get my brain round that, but I can't quite figure
out what you mean. Pair notation is, as I understand it, when you get
key => value
to construct a pair. Assuming that's me remembering correctly, then
where does the smart quoter have to deal with pair notation? Are you
considering allowing something like:
« key1 => flop key2 => floop »
Which would be
hash(key1 => flop, key2 => floop);
or am I completely off my rocker? I hope I am, because that's kind of
ugly. The only other thing I can think of is if you're just talking
about *implementing* infix:=>, in which case just ignore the above
because of course the autoquoter needs to recognise its left-hand-side.
As an aside, is it possible for us to define our own autoquoting
operators? I assume it will be, but I'm feeling insecure and need
reassurance.
I neglected to mention that we also naturally get both of:
circumfix:«< >»
circumfix:<« »>
in addition to
circumfix:{'<','>'}
circumfix:{'«','»'}
Have to be careful with
circumfix:«{ }»
though, since {...} interpolates these days.
Yes, that would be fun... almost worth throwing out a compiler warning
for that, especially if we've still got use warnings. Something like
Warning: «{ }» creates empty list
or even
Warning: circumfix:«{ }» creates empty operator
that one could be an error in fact.
or if you're feeling really nasty
Syntax error
Because I'm sure it should be wrong to create empty circumfix operators.
Or am I too prescriptive? My inner Haskell programmer is showing through.
Re: Angle quotes and pointy brackets
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Smylers) wrote: >David Green writes: >> I'm not even sure what those double-quotation marks are doing -- [...] >Look back at how Larry defined the guillemets: [...] >So the double-quotes in there are "shell-like", though I guess if you >don't have a Unix background that doesn't mean much to you. Ah, of course. I read that straight in one eye and out the other. =) -David "getting carried away with parallelogies that aren't quite there, but I like the new definition anyway" Green
Re: Angle quotes and pointy brackets
David Green writes:
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Larry Wall) wrote:
>
> >* The :w splitting happens after interpolation. So
> >« foo $bar @baz »
> >can end up with lots of words, while
> >« foo "$bar" "@baz" »
> > is guaranteed to end up with three "words".
>
> Now I'm a bit lost. I would've expected the quotes (") inside a
> different kind of quote («) to be taken literally (just as in 'foo
> "$bar" "@baz"' or qw/foo "$bar" "@baz"/).
> I'm not even sure what those double-quotation marks are doing --
> preventing $bar from being interpolated as a variable, or preventing
> the interpolated value from being white-split?
Look back at how Larry defined the guillemets:
> > * That frees up «...» for Something Else.
> >
> > * That something else is the requested variant of qw// that
> > allows interpolation and quoting of arguments in a shell-like
> > manner.
So the double-quotes in there are "shell-like", though I guess if you
don't have a Unix background that doesn't mean much to you. (Post again
if that's the case -- I have to leave for work now, but I'm sure
somebody here will be able to explain.)
Smylers
Iteration Again (was «Re: Angle quotes and pointy brackets»)
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Brent 'Dax' Royal-Gordon) wrote:
>I'm going to pull a Larry and think out
>loud for a minute here. Note that I speak authoritatively here,
Noted. Or not. =)
>Treating it like an array is wrong.
>On the other hand, what if a filehandle *is* an array? What if you
>can access it randomly and non-destructively?
I like this line of thought -- sure, arrays and iterators are
different, but they're also similar, so they ought to look similar in
at least some ways. We already think of files in a somewhat-array-
like manner ("Gimme line 42 of this file") rather than mere iterators
("Get the first 41 lines of this file, throw them away, and then gimme
the next one"), so why shouldn't Perl reflect that? Keeping the easy
things trivial and all...
An iterator can also be quite unlike an array (for instance a pipe,
where you can't jump back to the beginning, even inefficiently), but
I think those differences apply at a slightly higher level,
conceptually. (Or they would if we weren't forced by the language to
think of them differently at the lower level.) After all, if you
know you're dealing with a pipe, it would probably never even occur
to you to try accessing it randomly; on the other hand, if you don't
know whether your object is an array or a file or a pipe to begin
with, you're already in trouble.
>But .shift looks a bit awkward. I suggest a name change for .shift
>and .unshift, so that we have:
>
>push, pop
>pull, put
Hm, I like that, the parallelisms with the number of letters, and the
way they all begin with P. Plus the meanings make sense (you pull
something towards you -- that's the front end -- but when something
pops off, it goes flying away from you -- that's the back).
>So now we have:
>my $fh=open "foo.txt";
>say $fh.pull;
>for $fh.pullall {
I'm not crazy about "pullall". If the idea is we want to slurp up
the file right now, can't we use our flattening splatter? (for
[EMAIL PROTECTED] ...)
>And what about iterators in general? Well, if we can do it to
>filehandles, why not all iterators? An iterator is simply a lazy
>array copy that isn't accessed randomly;
Or maybe a lazy array is just an iterator (with some extra abilities
added on). But I'm all for taking advantage of the commonalities.
-David "which is related to another kind of laziness" Green
Re: Angle quotes and pointy brackets
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Larry Wall) wrote:
>Here's the proposal.
>First the bad news:
>* We accept that the C<< < >> operator requires whitespace
>around it, and be prepared to be burned in effigy occasionally.
I wouldn't go that far, although when I inevitably get burned by it,
I might let slip some intemperate comparisons regarding whitespace and
programming in Python... =)
>* That means that, roughly, we have this proportion:
>'...' : "..." :: <...> : «...»
I wasn't sure at first, but I think you just sold me. (I'm a sucker
for parallels.)
>* The :w splitting happens after interpolation. So
>« foo $bar @baz »
>can end up with lots of words, while
>« foo "$bar" "@baz" »
> is guaranteed to end up with three "words".
Now I'm a bit lost. I would've expected the quotes (") inside a
different kind of quote («) to be taken literally (just as in 'foo
"$bar" "@baz"' or qw/foo "$bar" "@baz"/).
I'm not even sure what those double-quotation marks are doing --
preventing $bar from being interpolated as a variable, or preventing
the interpolated value from being white-split?
(Of course, to keep the pattern going, I'd propose < for no
interpolation, << for interpolation (but not subsequent splitting), and
introduce <<< for going whole-hog and interpolating *with* subsequent
splitting. (Not that I'm saying I'd actually ever use <<>>, I just wanted to propose them for the parallelism.))
>* A rule like now captures, while «ws» or <> doesn't.
>I think I really like that last outcome. Capturing should be the default.
>And the low profile of «ws» makes it look like an "oh by the way".
I don't think I like that as much as you do. I'm not sure I *dislike*
it either... but I would be tempted to say that the double guillemets
should do twice as much (identify AND capture). That might be simply
because I'm not used to it, though. Either way, I know I really like
being able to drop the parentheses when capturing like that.
Overall, I think the new proposal is an improvement.
-David «foo» Green
Re: Angle quotes and pointy brackets
Larry Wall writes:
> The basic problem with «...» is that most of its uses were turning out
> to be more useful that the corresponding <...>. ... and I think I'm
> ready to propose a Great Angle Bracket Renaming.
I very much like your proposal. (Though whether you were actually ready
to propose it yet is obviously something only you can decide ...)
> * We steal angles away from iterators.
That means that Apocalypse 2 can be updated by _removing_ an existing
"[Update]" block!
Most of the complaints about non-Ascii characters in Perl relate to the
guillemets. With your proposal they are relegated to much less-commonly
constructs, and people who really don't like them can mostly avoid
having to go anywhere near them.
> * We get <...> as the qw// shorthand where a term is expected.
I like that. When Apocalypse 2 first came out I switched to using
angles as C delimiters most of the time, such as:
use Some::Module qw;
in an attempt to get used to them having that meaning, and so there's
less of a jump to Perl 6. Over 3 years later I can report that they
work very well for this.
> * Since we already stole angles from iterators, «$fh» is not
> how you make iterators iterate. Instead we use $fh.fetch (or
> whatever) in scalar context, and $fh.fetch or @$fh or $fh[]
> or *$fh in list context.
Good. That is the single thing I find hardest to teach to beginners in
Perl 5; output has an explicit C statement, but the input doesn't
appear to be anywhere in the code -- there's just some brackets in a
C loop, and it doesn't occur to people that brackets might have
the effect of reading from a file.
However, does anything in this proposal conflict with keeping C< <> > as
the special-case token for reading from standard-input-or-the-files-
named-on-the-command-line? That way people who like that super-short
idiom get to keep it, in:
for <> { ... }
while anybody who's gone to the bother of typing out a named stream has
to put a little more effort in to specify that iteration is required.
> * That means that, roughly, we have this proportion:
>
> '...' : "..." :: <...> : «...»
That makes good sense. It also means that people are free to continue
to ignore the variant they don't like (such as the many people who
prefer to use C<"> quotes in Perl 5 even when no interpolation is
required), which to some extent reduces the validity of any carping.
Bearing in mind how much more can now be done with out unicode (or ugly
C< << > variants) and I think this proposal should result in a nett
carping reduction (especially by people who don't following this mailing
list closely and therefore haven't been getting used to the previous
scheme -- I'm sure it'd be received better by those people who are yet
to meet any Perl 6 at all).
Smylers
Re: Angle quotes and pointy brackets
John Siracusa writes:
> Call me crazy, but at this point I'm prone to stick with what I've done in
> Perl 5 for years:
>
> $var{'key1'}{'key2'}[3]{'key3'}
In which case do that, since it'll still work in Perl 6.
Actually, it works 'better' in Perl 6, since it doesn't mislead in any
way.
I've encountered several Perl programmers who feel 'uneasy' about the
auto-quoting rules of hash keys, so choose not to bother with them and
put all the quotes in as you do above. The trouble with that in Perl 5
is that it gives the impression that the quotes are actually doing
something. That then leads to bugs like writing:
$log{time} = $msg;
where because the programmer has explicitly _not_ used quotes and want
to invoke a function rather than use the literal string "time". But
because in fact the quotes weren't doing anything, removing them doesn't
change anything.
That awkwardness is fixed in Perl 6: because the quotes _are_ now needed
with the C< $hash{'key'} > syntax when you want to quote, you can not
have quotes when you don't want to quote (and Perl will automatically
not quote it for you!).
So life is better for people who like writing hash subscripts as you do.
But for those who like autoquoting, there's now a different syntax, one
that doesn't interfere with the above syntax at all. You don't have to
use it if you don't want to, and everybody's happy!
Smylers
Re: Angle quotes and pointy brackets
On Tue, 30 Nov 2004 19:10:48 -0800, Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> wrote: > John Siracusa <[EMAIL PROTECTED]> wrote: > > On 11/30/04 9:54 PM, Matt Diephouse wrote: > > > use CGI «:standard»; > > > [...] > > > use CGi <:standard>; > > > > Who is doing this? I'm just saying... > > > >use CGI ':standard'; > > And won't we just be doing: > > use CGI :standard; > > anyway? Indeed. Also, someone *ahem* will make the following work, with or without the C<.> %hash.:foo:bar:baz = 10; Ashley Winters
Re: Angle quotes and pointy brackets
On Tue, 30 Nov 2004 19:10:48 -0800, Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> wrote: > John Siracusa <[EMAIL PROTECTED]> wrote: > > Who is doing this? I'm just saying... > > > >use CGI ':standard'; I normally use qw// when use-ing. *shrug* > And won't we just be doing: > > use CGI :standard; > > anyway? Yeah, we will; I forgot. :-) I don't use Perl 6 very often (yet). -- matt diephouse http://matt.diephouse.com
Re: Angle quotes and pointy brackets
All the cool kids are thinking aloud these days. Why not jump on the bandwagon? Larry Wall writes: > * We get the cute, clean and rather more typeable > > $var[3] It looks like if you shook that up and down a bit, it would break in half. I wonder what would happen if we made <> a little smarter, as in: * acts as a multidimensional subscript (* but what for @array = ?) * <+42> returns a number instead of a string. Then: $var Which is certainly less noisy than the kitkat above. Problems: * -foo is common for options; don't want to force a number. Then again, you don't see -6 as an option too often. * Doesn't solve anything in the practical scenario where some of your keys are not constant. But we'd, of course, do the same thing to ÂÂ. However, there's a problem with ÂÂ: it doesn't generalize to non-string keys (since Â$foo can reasonably only stringify). That is: $varÂfoo ; $bar ; +3 Doesn't work if $bar is something unstringly that happens to be the key type of the second dimension. Not to mention that if we allowed semicolon,  would be the common one again, and we'd be in for another switcheroo. Anyway, I think there's something wrong with: $var[3] It doesn't hold together visually. This might have some relation to the other problem on my mind: the difference between $, @, and % these days. The rest of the proposal is pretty snazzy, though. Luke
Re: Angle quotes and pointy brackets
John Siracusa <[EMAIL PROTECTED]> wrote: > On 11/30/04 9:54 PM, Matt Diephouse wrote: > > use CGI «:standard»; > > [...] > > use CGi <:standard>; > > Who is doing this? I'm just saying... > >use CGI ':standard'; And won't we just be doing: use CGI :standard; anyway? -- Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> Perl and Parrot hacker "I might be an idiot, but not a stupid one." --c.l.p.misc (name omitted to protect the foolish)
Re: Angle quotes and pointy brackets
On 11/30/04 9:54 PM, Matt Diephouse wrote: > use CGI «:standard»; > [...] > use CGi <:standard>; Who is doing this? I'm just saying... use CGI ':standard'; It really ain't all that broke, is it? -John
Re: Angle quotes and pointy brackets
On Tue, 30 Nov 2004 13:35:37 -0800, Larry Wall <[EMAIL PROTECTED]> wrote: > The basic problem with «...» is that most of its uses > were turning out to be more useful that the corresponding <...>. > In fact, I was thinking about all this on the way home from Seattle > yesterday (a 15-hour drive), and I think I'm ready to propose a Great > Angle Bracket Renaming. I'm going to be difficult and say I don't actually like this proposal. I think « and » are much more attractive than < and >, and I don't mind the extra work to type them. « and » are more visually distinctive, at least in my mind. Specifically, I like that they line up with the tops of lower case letters. But I doubt that matters much. :-) use CGI «:standard»; my @list = «foo bar baz»; my @other = %hash«several keys here»; use CGi <:standard>; my @list = ; my @other = %hash; (Those are written out for my own benefit; consider it a goodbye.) -- matt diephouse http://matt.diephouse.com
Re: Angle quotes and pointy brackets
On 11/30/04 6:35 PM, James Mastros wrote:
> Austin Hastings wrote:
>> Larry Wall wrote:
>>>* We get the cute, clean and rather more typeable
>>>
>>> $var[3]
"Cute" maybe (looks like a chain of fish)
> The problem with {} for a hash dereference operator is not it's
> typeablility, but rather it's autoquoting behavior from perl5.
Call me crazy, but at this point I'm prone to stick with what I've done in
Perl 5 for years:
$var{'key1'}{'key2'}[3]{'key3'}
It's the same number of characters as:
$var<><>[3]<>
and it requires no "funny" characters. I also find it a heck of a lot more
readable than any of the others. The {' '} makes a nice vertical +
whitespace "frame" around the key. The fake doubles << and >> are way too
noisy. The funny quotes look wildly different in different fonts, but
usually end up as indistinct smudges that resemble melted "=" characters.
> OTOH, $wheel. and $wheel. are both literals. (The dot
> there is optional.) (Until a little bit ago, that was $wheel.<>
> or $wheel.«roll». (Note that I had to switch keyboard layouts again to
> type that.))
I agree that $wheel is an improvement over $wheel«roll» and
$wheel<> (although I can't decide which of those two is worse), but I
still think $wheel{'roll'} is the clear winner in all respects except
perhaps speed of typing.
-John
Re: Angle quotes and pointy brackets
On Tue, Nov 30, 2004 at 03:03:38PM -0800, Jon Ericson wrote:
: Larry Wall <[EMAIL PROTECTED]> writes:
:
: > The p5-to-p6 translator will turn any
: >
: > while () {...}
: >
: > into
: >
: > for @$handle {...}
:
: Including:
:
: while(<>) {...}
:
: to
:
: for @$ {...}
:
: ?
You left out the most important phrase:
"or whatever we decide is the correctest idiom."
So if, as has been pointed out, @$handle is too much role shear, then we
probably go with something like
for *$handle {...}
in which case, if there's no handle, it seems to degrade to
for * {...}
which seems amazingly something or other.
Larry
Re: Angle quotes and pointy brackets
On Tue, Nov 30, 2004 at 06:27:55PM -0500, Matt Fowles wrote: : Even if he wasn't cackling, I admit to feeling it. I don't even use : the qx/qq/qw stuff in perl5. I always got by with "". : : Although I must admit to liking python's C< r"..." > meaning : absolutely raw string (useful for avoiding double escape problems with : their regular expressions). Left me thinking it was short for regex : and not raw for a little while... Actually, I was thinking about a raw option, so q:r could be it. And it might actually turn out to be useful for quoting rules if for some reason you really don't want to write an rx//. And oddly, it might end up with a qr// shorthand. So we might end up with qr:here'END' for the Perl 6 equivalent to <<'END'. Larry
Re: Angle quotes and pointy brackets
On Tue, Nov 30, 2004 at 05:39:29PM -0700, Luke Palmer wrote: : I don't know what argumentless shift does now. It probably works on : @*ARGS when you're in the main program, but inside a sub... I dunno. : Maybe it shifts from the slurpy array argument. Shifting on the topic : seems wrong (since you could use .shift for that). I'd say it always shifts the slurpy array, and in Main the slurpy array just happens to be named [EMAIL PROTECTED] Larry
Re: Angle quotes and pointy brackets
James Mastros writes:
> The problem with {} for a hash dereference operator is not it's
> typeablility, but rather it's autoquoting behavior from perl5. In
> perl5, the contents of {foo} are a string -- except when they aren't.
> Quick:
>
> $wheel->{roll} = 3;
> $wheel->{shift} = 4;
>
> In perl5, the first is a literal, the second shifts from @_. Whoops.
That's wrong. I can't determine whether you knew it was wrong, and
your final assessment sentence was intentionally wrong (thus "Whoops").
But, in Perl 5, they're both literals.
> In perl6, the contents of {} is an expression. The first is an error
> unless a function named roll is available (or a method on the topic?).
> The second is good old shift (on the topic now).
I don't know what argumentless shift does now. It probably works on
@*ARGS when you're in the main program, but inside a sub... I dunno.
Maybe it shifts from the slurpy array argument. Shifting on the topic
seems wrong (since you could use .shift for that).
Luke
Re: Angle quotes and pointy brackets
On Tue, Nov 30, 2004 at 02:26:06PM -0800, Brent 'Dax' Royal-Gordon wrote: : Larry Wall <[EMAIL PROTECTED]> wrote: : > * Since we already stole angles from iterators, «$fh» is not : > how you make iterators iterate. Instead we use $fh.fetch (or : > whatever) in scalar context, and $fh.fetch or @$fh or $fh[] : > or *$fh in list context. : : I believe you tried this one a couple years ago, and people freaked : out. As an alternative, could we get a different operator for this? : I propose one of: : : $fh -> : $fh» (and $fh>>) : $fh> : : All three have connotations of "the next thing". The first one might : interfere with pointy subs, though, and the last two would be : whitespace-sensitive. (But it looks like that isn't a bad thing : anymore...) In lines with the '...' "..." and <...> <<...>> progressions, the following progression has a nice symmetry: $iter -->#extract next (one) element from iterator $iter $iter ==>#pipeline all elements (lazy) in turn from iterator $iter However, I haven't been paying a lot of attention, to the current state of affairs, so it is probably broken in some way. --
Re: Angle quotes and pointy brackets
> "AH" == Austin Hastings <[EMAIL PROTECTED]> writes:
AH> Larry Wall wrote:
>> * We get the cute, clean and rather more typeable
>>
>> $var[3]
>>
AH> No more or less typeable for me, or anyone else who can remap their
AH> keyboard. I'm presuming there's something costly about {} on non-US
AH> keyboards, but how much does it cost? and do those non-US perl hacks
AH> use remapping already?
i think the diff between $hash<> and $hash{} is that <> autoquotes (and
only allows) single words and {} requires quote words or expressions. so
$hash is the same as $hash{'foo'}. $hash{foo} is either a syntax
error or something i can't figure out (foo is a bareword which is
illegal IIRC).
>> * People can probably get used to reading things like:
>>
>> $var[3] < $var[4]
>>
AH> It's just as readable as XML.
it is only for fixed token keys and who actually writes hash accesses
that deep and very often? i would assign the midlevel hashes to a scalar
and work from there if this was common code.
AH> Carp.
AH> Carp.
AH> Carp.
main::Carp can't be found. Perhaps you forgot to use the Carp
qw(no_carping_at_larry)? :)
uri
--
Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs http://jobs.perl.org
Re: Angle quotes and pointy brackets
> "MW" == Matthew Walton <[EMAIL PROTECTED]> writes: MW> I don't think I've ever used a hash slice in my life. Is there MW> something wrong with me? yes! :) see http://www.sysarch.com/perl/tutorials/hash_slice.txt for why they are so cool. >> * The Texas quotes <<...>> are only needed when you *have* to interpolate. MW> Does MW> <> MW> mean MW> «foo bar baz» i would hope << and >> always mean the same as their unicode versions. i will be typing the long asci versions for as long as it takes me to learn how to key the unicode in emacs (i know people have posted answers for emacs but it still takes my tiny brane a while to learn new keystrokes). >> * Match vars become $ instead of $«foo». >> * A rule like now captures, while «ws» or <> doesn't. >> I think I really like that last outcome. Capturing should be the >> default. >> And the low profile of «ws» makes it look like an "oh by the way". i thought we had very different capturing and non-capturing syntax? and with equal key counts as well. but i could be out of date with regard to rules and grammars. i dread ruining more brane cells reading the recent updated apocs and such. :) uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: Angle quotes and pointy brackets
Austin Hastings wrote:
Larry Wall wrote:
* We get the cute, clean and rather more typeable
$var[3]
No more or less typeable for me, or anyone else who can remap their
keyboard. I'm presuming there's something costly about {} on non-US
keyboards, but how much does it cost? and do those non-US perl hacks use
remapping already?
German keyboard, for example:
{ -- right alt, and the 7 key
[ -- right alt, and the 8 key
] -- right alt, and the 9 key
} -- right alt, and the 0 key
German keyboard under xfree86 but not windows:
« -- right alt, z (Well, the key that's z on an American keyboard).
» -- right alt, x
Those are /really/ hard to type, esp }, which comes up a /lot/ in perl,
weather 5 or 6, which is a big reason that I use the American keymap,
which is a constant annoyance to my girlfriend, who uses the British
keymap. (We're an American and a Brit, living in Germany.)
The problem with {} for a hash dereference operator is not it's
typeablility, but rather it's autoquoting behavior from perl5. In
perl5, the contents of {foo} are a string -- except when they aren't.
Quick:
$wheel->{roll} = 3;
$wheel->{shift} = 4;
In perl5, the first is a literal, the second shifts from @_. Whoops.
In perl6, the contents of {} is an expression. The first is an error
unless a function named roll is available (or a method on the topic?).
The second is good old shift (on the topic now).
OTOH, $wheel. and $wheel. are both literals. (The dot
there is optional.) (Until a little bit ago, that was $wheel.<>
or $wheel.«roll». (Note that I had to switch keyboard layouts again to
type that.))
-=- James Mastros
Re: Angle quotes and pointy brackets
Rod Adams <[EMAIL PROTECTED]> wrote:
> >$fh ->
> >$fh» (and $fh>>)
> >$fh>
> ++$fh
That kind of breaks the metaphor, unfortunately.
I've been thinking more on this, and I may have a better reason for
not liking this proposal. I'm going to pull a Larry and think out
loud for a minute here. Note that I speak authoritatively here, as if
I'm the language designer; this is just to avoid putting "I would..."
everywhere.
I think my problem with the proposed syntax is metaphor shear. This
example code:
for (@$input) {
...
}
works whether $input is a filehandle or an arrayref. So a user may
decide to do this:
say $input[42];
which I suspect won't work. Even if it does, this code:
for(@$input) {
...
}
say $input[0];
probably wouldn't.
The problem is that filehandles are iterators--which aren't arrays.
An iterator has different characteristics from an array--i.e. it's
accessed more or less sequentially and access is destructive.
Treating it like an array is wrong.
On the other hand, what if a filehandle *is* an array? What if you
can access it randomly and non-destructively?
If it is, we already have a name for "fetch". In Perl 5, we call a
destructive fetch from the front of an array "shift".
So:
$fh=open "foo.txt";
say $fh.shift;
for $fh.shift($fh.elems) {
...
}
Of course, $fh.shift($fh.elems) deserves a shortcut. Perhaps
$fh.shiftall(), which creates a lazy copy and "empties" the
filehandle.
But .shift looks a bit awkward. I suggest a name change for .shift
and .unshift, so that we have:
push, pop
pull, put
So now we have:
my $fh=open "foo.txt";
say $fh.pull;
for $fh.pullall {
...
}
And what about iterators in general? Well, if we can do it to
filehandles, why not all iterators? An iterator is simply a lazy
array copy that isn't accessed randomly; instead, the .pull and
.pullall methods are used for access. .push can be used to append to
it, .put can be used to put an item back on the front. .pop is a bit
useless, but that's not really a problem.
That doesn't mean you *can't* randomly access an iterator--after all,
it's just a lazy array copy. But it might be slower, or otherwise
unwise.
At the point where a filehandle is just an array and you can use most
normal array operations on it, I can see not having a special operator
for reading a file. Without that, though, I think the metaphor shear
of @$fh is too harsh, and the duplication between .fetch and
.[shift|pull] isn't necessary.
--
Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]>
Perl and Parrot hacker
"I might be an idiot, but not a stupid one."
--c.l.p.misc (name omitted to protect the foolish)
Re: Angle quotes and pointy brackets
Austin~ On Tue, 30 Nov 2004 18:15:54 -0500, Austin Hastings <[EMAIL PROTECTED]> wrote: > Austin Hastings wrote: > > > Larry Wall wrote: > > And now, Piers is cackling madly at Matt: welcome to "perl6-hightraffic!" > > :-) Even if he wasn't cackling, I admit to feeling it. I don't even use the qx/qq/qw stuff in perl5. I always got by with "". Although I must admit to liking python's C< r"..." > meaning absolutely raw string (useful for avoiding double escape problems with their regular expressions). Left me thinking it was short for regex and not raw for a little while... Matt -- "Computer Science is merely the post-Turing Decline of Formal Systems Theory." -???
Re: Angle quotes and pointy brackets
Austin Hastings wrote: Larry Wall wrote: And now, Piers is cackling madly at Matt: welcome to "perl6-hightraffic!" :-) =Austin
Re: Angle quotes and pointy brackets
Larry Wall wrote: I'm ready to propose a Great Angle Bracket Renaming. Hajleuja! Praise the Larry!* It looks wonderful, and just fixed half about half the things I was worried about having to do when programming perl6. (Not that hard -- I can't think of any more at the moment, but I'm sure they're there somewhere.) -=- James Mastros *I think I just broke two or three commandments.
Re: Angle quotes and pointy brackets
Larry Wall wrote:
* We get the cute, clean and rather more typeable
$var[3]
No more or less typeable for me, or anyone else who can remap their
keyboard. I'm presuming there's something costly about {} on non-US
keyboards, but how much does it cost? and do those non-US perl hacks use
remapping already?
* People can probably get used to reading things like:
$var[3] < $var[4]
It's just as readable as XML.
* Though they will certainly carp.
Carp.
Carp.
Carp.
* The ordinary angles do a better job of turning the
literal keys into visual pills than «...» do.
What're the objectives here again?
Sorry, but <> don't turn ANYTHING into "visual pills". They never have.
(HT|X)ML looks like gobbledygook interspersed with low-slung X's. The
line above reads like a IOCCC loser.
* Since we already stole angles from iterators, «$fh» is not
how you make iterators iterate. Instead we use $fh.fetch (or
whatever) in scalar context, and $fh.fetch or @$fh or $fh[]
or *$fh in list context.
while ($.fetch)
??
* That frees up «...» for Something Else.
* That something else is the requested variant of qw// that allows
interpolation and quoting of arguments in a shell-like manner.
Sorry, why wouldn't `` work?
How about just having C< system() > return a clever object with .output
and .err methods?
* That means that, roughly, we have this proportion:
'...' : "..." :: <...> : «...»
Have we discussed which quote-like operator is going to stand for "eval"?
There's a number of different post-processing things you can do with
string literals, with interpolation at one end of the spectrum and
execution at the other.
Why not just write this down as "these are all just special cases of XXX
behavior", and then build some handles onto XXX, a la NEXT, LAST, etc.
Then provide "standard bindings" for '', ``, "", and //.
* Therefore, just as you can use "..." in place of '...' where you
you think it's more readable, you may still use «...» in place
of <...> where that helps readability.
my $foo = `*.c` :post(literal); # *.c
my $bar = /$foo/ :post(glob); # a.c b.c ...
my $cmd = 'echo $foo' :post(interpolate); # echo *.c
my $output = q{$cmd} :post(exec);# *.c
my $files = "$cmd" :post(shell); # a.c b.c ...
$var«key1»«key2»[3]«key3» < $var«key1»«key2»[4]«key3»
I'm looking for the goodness, and I'm just preferring the more vertical
{} as parallels with [].
* The Texas quotes <<...>> are only needed when you *have* to interpolate.
Not even a little bit sure what this means. If non-interpolation is an
option, put a modifier on it.
* Multimethed references could be distinghuised either way:
&bark«Tree»
&bark
At some point, nestled « was considered a short-circuit of the
paren/hash. Is that supposed to stand, or are those quotes?
* Match vars become $ instead of $«foo».
Seems independent of the others. Is this just a consistency issue?
* A rule like now captures, while «ws» or <> doesn't.
So <...>, which is analogous to '...' above, doesn't interpolate but
does capture? While «...», which is analogous to "...", does interpolate
but doesn't capture?
I think I really like that last outcome. Capturing should be the default.
And the low profile of «ws» makes it look like an "oh by the way".
I think that last sentence sums it up: using «ws» is less visually
obvious. For scenarios where we don't want visual obviousness, like
string delimiters, that's probably a win. I really don't want stealth
paint on my data infrastructure, though.
Larry
=Austin
