Re: Revision of A12's lookahead notions
> "LW" == Larry Wall <[EMAIL PROTECTED]> writes:
LW> 1c) Explicit parentheses may delimit the actual arguments,
LW> in which case the function is parsed as a function rather
LW> than a list operator. Adverbs may follow the parens:
LW> splurt(1,2,3):by{ +$_ } # okay
LW> splurt(1,2,3):{ +$_ } # okay (implicit binding to *& param)
LW> splurt 1,2,3# okay (assumed to be list operator)
LW> splurt; # okay, 0-arg list
LW> splurt() + 1# okay, explicit 0 arg list
LW> splurt + 1 # wrong unless predeclared 0-ary
can you have a 0- or 1-ary function? meaning like the many funcs that
work on $_ with no args or the single arg you pass in. how do you
declare it so it parses correctly?
splurt # should work on $_
splurt()# should work on $_
splurt + 1 # same??
splurt +1 # work on +1??
splurt( +1 )# definitely work on +1
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
Mailing list archives
There's something wrong with the mailing list archives at http://dev.perl.org/perl6/lists/. I can get to this page OK, but when I click on a link to the perl6-internals or perl6-language archives, I get a "This page cannot be displayed" error. Joe Gottman
Re: Mailing list archives
Joe Gottman wrote: There's something wrong with the mailing list archives at http://dev.perl.org/perl6/lists/. I can get to this page OK, but when I click on a link to the perl6-internals or perl6-language archives, I get a "This page cannot be displayed" error. The perl.org list server's been having some fairly serious trouble, according to what I read on Planet Perl. That would probably also explain why the list has been so quiet lately.
Re: Why do users need FileHandles?
On Sat, Aug 07, 2004 at 03:55:21PM +0100, Nicholas Clark wrote:
> On Sat, Jul 24, 2004 at 02:50:18PM -0700, David Storrs wrote:
> > #!/usr/bin/perl6
>
> #!/usr/bin/perl
I stated perl6 explicitly to be, well, explicit.
> > #use warnings; # Note that I am NOT explicitly using these
> > #use strict;
> >
> > { no 'warnings'; no 'strict'; # These must be explicitly turned off...
> > no installation_security; # or this would throw warning & error
>
> use Acme::Intraweb;
>
> > use SomeModule; #
> > use OtherModule;#
> > use Foo;# If these are not installed,
> > use Bar;# they will be auto-installed.
> > use Baz;#
> > use Jaz;#
> > }
>
>
> However, Acme::Intraweb hasn't been updated for a while, whereas CPANPLUS
> has, so I'm not sure if it still works. Both are by Jos Boumans.
Urrmmm...ok, I'm sure I'm just being dense here, but I do not see your
point. Can you unpack it for me?
--Dks
Re: Why do users need FileHandles?
On Wed, Aug 11, 2004 at 03:25:20PM -0700, David Storrs wrote: > On Sat, Aug 07, 2004 at 03:55:21PM +0100, Nicholas Clark wrote: > > However, Acme::Intraweb hasn't been updated for a while, whereas CPANPLUS > > has, so I'm not sure if it still works. Both are by Jos Boumans. > > Urrmmm...ok, I'm sure I'm just being dense here, but I do not see your > point. Can you unpack it for me? IIRC you said "it would be good if perl6 could do this" My point was that Jos wrote a module for perl5 that could do this last year. However, I suspect if you attempt to install it from CPAN today it will break, because it's not been updated to cope with changes to CPANPLUS, upon which it depends. Nicholas Clark
Re: Revision of A12's lookahead notions
On Tue, Aug 10, 2004 at 06:10:17PM -0400, Uri Guttman wrote: : can you have a 0- or 1-ary function? meaning like the many funcs that : work on $_ with no args or the single arg you pass in. how do you : declare it so it parses correctly? : : splurt # should work on $_ : splurt()# should work on $_ : splurt + 1 # same?? : splurt +1 # work on +1?? : splurt( +1 )# definitely work on +1 Yes, functions declared with a single optional argument end up parsed as named unaries, as in Perl 5 (though Perl 5 merely assumed that a single argument was optional). The "greedy function" rule still applies in that it will try to look for an argument, and only default to being 0-ary if it can't find an argument. And functions declared 0-ary explicitly parse as terms, while all 2-ary and higher functions parse as list operators unless you use parens. (All functions are considered to be list ops before declaration, and if the declaration subsequently changes that fact, it's an error. So 0-ary and 1-ary functions have to be predeclared if you want them to parse as unaries.) I think this is all consistent and useful, but of course I could simply be wrong, or more likely, wrongish. Larry
Re: Handling block parameters in Ruby
On Fri, Aug 13, 2004 at 02:12:06PM +0100, mark sparshatt wrote:
: My main worry with this approach is how it would interact with slurpy
: args. I mean if method is defined as
:
: def method(*args)
: ...
: end
:
: how do I make sure that $clos doesn't become part of args?
In Perl 6 circles we've been considering that a signature declaration
could have a "slurpy function" as well as slurpy arrays and hashes.
The magic block would actually be processed as a named argument with
an implicit name, so there's no problem with where to pass it in the
positional arguments. This maps pretty well onto Ruby's magic blocks
(and admittedly was inspired by it), though Perl will have different
syntactic rules about how to pass one, of course, because we're
generalizing the concept somewhat. In particuler, one way to pass
a magic block is as an anonymous adverb: C<< :{...} >>. I suspect
it can also be passed as the final element on the slurpy list,
from which it could be removed at either compile time or call time.
Or it could be passed as an explicitly named parameter. That's
what I mean by generalizing Ruby's concept--there's no "magic" syntax
for blocks--it's just another named parameter, where the name can
sometimes be omitted on the call. It's always declared with a name
on the receiving end, and there's no magic "yield" on an implicit
closure. Just call the named closure.
[I've cc'd p6l, so please send replies to the appropriate list.]
Larry
Re: Handling block parameters in Ruby
On Fri, 13 Aug 2004 10:46:45 -0700, Larry Wall <[EMAIL PROTECTED]> wrote:
> This maps pretty well onto Ruby's magic blocks
> (and admittedly was inspired by it), though Perl will have different
> syntactic rules about how to pass one, of course, because we're
> generalizing the concept somewhat. In particuler, one way to pass
> a magic block is as an anonymous adverb: C<< :{...} >>. I suspect
> it can also be passed as the final element on the slurpy list,
> from which it could be removed at either compile time or call time.
> Or it could be passed as an explicitly named parameter. That's
> what I mean by generalizing Ruby's concept--there's no "magic" syntax
> for blocks--it's just another named parameter, where the name can
> sometimes be omitted on the call. It's always declared with a name
> on the receiving end, and there's no magic "yield" on an implicit
> closure. Just call the named closure.
All this talk of blocks and Ruby (and A12 Lookahead Notions) brings up
an important question in my mind: how will Perl 6 handle multiple
blocks? When using Ruby, I found blocks both easy and pretty. But I
found writing a method with multiple blocks to be both less easy and
less pretty.
>From what I understand, something like this will be possible (but will
it need parens?):
@array.each :odd{ $^odd.bar() } :even{ $^even.baz() };
But what about this?
@array.each:{$^odd.bar() }:{ $^even.baz() };
Admittedly it's a much smaller case, but it should be useful, even if
I can't think of a non trivial case offhand.
--
matt diephouse
--
http://matt.diephouse.com
>
> Larry
>
Re: Handling block parameters in Ruby
On Fri, Aug 13, 2004 at 02:21:30PM -0400, Matt Diephouse wrote:
: All this talk of blocks and Ruby (and A12 Lookahead Notions) brings up
: an important question in my mind: how will Perl 6 handle multiple
: blocks? When using Ruby, I found blocks both easy and pretty. But I
: found writing a method with multiple blocks to be both less easy and
: less pretty.
Yes, that's precisely why I'm trying to generalize Ruby's single
"magic" block into one or more ordinary parameters.
: >From what I understand, something like this will be possible (but will
: it need parens?):
:
: @array.each :odd{ $^odd.bar() } :even{ $^even.baz() };
No parens necessary there. But parens are necessary if you want to
pass any non-adverbial arguments to a method. On the other hand, since
adverbs are just named parameters you can also write that:
@array.each( :odd{ $^odd.bar() } :even{ $^even.baz() } );
or equivalently
@array.each( 'odd' => { $^odd.bar() }, 'even' => { $^even.baz() } );
: But what about this?
:
: @array.each:{$^odd.bar() }:{ $^even.baz() };
:
: Admittedly it's a much smaller case, but it should be useful, even if
: I can't think of a non trivial case offhand.
Two anonymous adverbs? Hmm. While I can think of ways to force it to
work, I'm inclined to disallow it simply because it'd make another
arbitrary rule we'd have to explain.
You know, at some point you just break down and write them positionally:
@array.each( { $^odd.bar() }, { $^even.baz() });
On the other hand, the parser will have to deal with multi-block
structures all the time, so perhaps something could be modelled on
how we eventually handle if/elsif/else, presuming we actually
declare those as macros, and not strictly as grammar rules.
Larry
Re: Revision of A12's lookahead notions
> "LW" == Larry Wall <[EMAIL PROTECTED]> writes: LW> On Tue, Aug 10, 2004 at 06:10:17PM -0400, Uri Guttman wrote: LW> : can you have a 0- or 1-ary function? meaning like the many funcs that LW> : work on $_ with no args or the single arg you pass in. how do you LW> : declare it so it parses correctly? LW> : LW> : splurt # should work on $_ LW> : splurt()# should work on $_ LW> : splurt + 1 # same?? LW> : splurt +1 # work on +1?? so how do the 2 above get parsed? the space between + and 1 looks alike a 0-ary splurt but the +1 could be 0-ary added to 1 or unary with +1 as its arg. this could mean a form of white space sensitivity. LW> : splurt( +1 )# definitely work on +1 LW> And functions declared 0-ary explicitly parse as terms, while all 2-ary LW> and higher functions parse as list operators unless you use parens. LW> (All functions are considered to be list ops before declaration, LW> and if the declaration subsequently changes that fact, it's an error. LW> So 0-ary and 1-ary functions have to be predeclared if you want them LW> to parse as unaries.) that all makes sense as all is fair if you predeclare and the default parsing is well documented and understood. LW> I think this is all consistent and useful, but of course I could simply LW> be wrong, or more likely, wrongish. depends on how you parse wrong! :) 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: Revision of A12's lookahead notions
On Fri, Aug 13, 2004 at 07:05:28PM -0400, Uri Guttman wrote: : LW> : splurt + 1 # same?? : LW> : splurt +1 # work on +1?? : : so how do the 2 above get parsed? the space between + and 1 looks alike : a 0-ary splurt but the +1 could be 0-ary added to 1 or unary with +1 as : its arg. this could mean a form of white space sensitivity. That's the sort of whitespace dependency we're trying to avoid now. So those both mean splurt(+1). I suppose the first form could be made to spit a warning since it's probably a mistake. But it's no worse than the situation in Perl 5 in that regard where you have to write splurt() + 1 if that's what you mean. Larry
Re: Handling block parameters in Ruby
On Fri, 13 Aug 2004 11:36:05 -0700, Larry Wall <[EMAIL PROTECTED]> wrote:
> Yes, that's precisely why I'm trying to generalize Ruby's single
> "magic" block into one or more ordinary parameters.
Excellent. :)
> Two anonymous adverbs? Hmm. While I can think of ways to force it to
> work, I'm inclined to disallow it simply because it'd make another
> arbitrary rule we'd have to explain.
And there's quite a bit to explain already.
> You know, at some point you just break down and write them positionally:
>
> @array.each( { $^odd.bar() }, { $^even.baz() });
Speaking of which, let's talk a little bit about how I'd write these
methods. After looking at Apocalypse, Exegesis, and Synopsis 6 again,
I have a few more questions. There are two different ways used to
declare a subroutine or method:
sub foo (&block) {
&block('foo');
}
and
sub foo (Code $block) {
$block('foo');
}
Which is right? both? The second seems more extensible. And that leads
me to another question: can a slurpy array pick up a block?
sub foo ([EMAIL PROTECTED]) {
say ref @args[0]; # @args[0].type?
}
foo { $^a =~ /bar/ }; # does this print "Block\n"?
It'd be nice to be able to declare my each method like so:
class Array {
method each($self: [EMAIL PROTECTED]) {
my $i = 0;
my @results;
for @$self -> $elem {
my $block = @blocks[ $i++ % [EMAIL PROTECTED] ];
@results.push( $block($elem) );
}
return @results;
}
}
But that still doesn't let me call that like I'd want;
my @r = @array.each :{ $^first * 2 }
:{ $^second * 9 }
:{ $^third * 42 };
The other thing I'm wondering is how to apply adverbs to the results
of a function, if that's even possible. I believe this is valid:
my $odd = 1... :by(2) # an infinite list of odd numbers
But this?
sub odd_numbers([EMAIL PROTECTED] of Pair) {
return 1...;
}
my $odd = odd_numbers :by(2);
Does that pass C 2> as a Pair to the function? Or does it apply
the adverb to the result? Maybe I need to do this?
my $odd = (odd_numbers) :by(2);
My head is swimming at this point, so I'd better give it a rest.
matt
> On the other hand, the parser will have to deal with multi-block
> structures all the time, so perhaps something could be modelled on
> how we eventually handle if/elsif/else, presuming we actually
> declare those as macros, and not strictly as grammar rules.
>
> Larry
Re: Revision of A12's lookahead notions
> "LW" == Larry Wall <[EMAIL PROTECTED]> writes: LW> On Fri, Aug 13, 2004 at 07:05:28PM -0400, Uri Guttman wrote: LW> : LW> : splurt + 1 # same?? LW> : LW> : splurt +1 # work on +1?? LW> : LW> : so how do the 2 above get parsed? the space between + and 1 looks alike LW> : a 0-ary splurt but the +1 could be 0-ary added to 1 or unary with +1 as LW> : its arg. this could mean a form of white space sensitivity. LW> That's the sort of whitespace dependency we're trying to avoid now. LW> So those both mean splurt(+1). I suppose the first form could be LW> made to spit a warning since it's probably a mistake. But it's no LW> worse than the situation in Perl 5 in that regard where you have to LW> write splurt() + 1 if that's what you mean. i have no issue with splurt() being needed to disambiguate. i just wanted to see your take (this week :) on it as i felt the table was ambiguous so far. as far as making it a warning, wouldn't that make the warning space sensitive? :-/ 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: Handling block parameters in Ruby
On Fri, Aug 13, 2004 at 08:41:35PM -0400, Matt Diephouse wrote:
: > You know, at some point you just break down and write them positionally:
: >
: > @array.each( { $^odd.bar() }, { $^even.baz() });
:
: Speaking of which, let's talk a little bit about how I'd write these
: methods. After looking at Apocalypse, Exegesis, and Synopsis 6 again,
: I have a few more questions. There are two different ways used to
: declare a subroutine or method:
:
: sub foo (&block) {
: &block('foo');
: }
The second & is unnecessary there. If you declare a &foo, you get foo() for free.
: sub foo (Code $block) {
: $block('foo');
: }
:
: Which is right? both? The second seems more extensible.
Either should work. Scalars are always more general, since they can
hold anything. But sometimes the point is to be less general...
: And that leads
: me to another question: can a slurpy array pick up a block?
:
: sub foo ([EMAIL PROTECTED]) {
: say ref @args[0]; # @args[0].type?
: }
Probably "typeof", actually, since "ref" is unclear, and "type" is
a keyword that prevents an indirect object syntax. Though arguably
"type" should be "subtype" or "constrain" or some such, which would
free up "type" for a unary.
: foo { $^a =~ /bar/ }; # does this print "Block\n"?
Maybe something more like "Code". Haven't revisited the
Code hierarchy in a while though. But the signature type
is in angles (this week), since parens are taken for actual
arguments.
: It'd be nice to be able to declare my each method like so:
:
: class Array {
: method each($self: [EMAIL PROTECTED]) {
Could go as far as to say Code [EMAIL PROTECTED], I expect. And you can
probably get away with @self too. (I also wouldn't call it "each",
since there's likely to be a built-in of that name, but I understand
you're just playing here...)
method roundrobin(@self: Code [EMAIL PROTECTED]) {
: my $i = 0;
: my @results;
: for @$self -> $elem {
: my $block = @blocks[ $i++ % [EMAIL PROTECTED] ];
The + is redundant there, though okay as documentation, which
I suppose is why you put it.
: @results.push( $block($elem) );
You can also write those two lines as:
my &block = @blocks[ $i++ % [EMAIL PROTECTED] ];
@results.push( block($elem) );
or as
@results.push( @blocks[ $i++ % [EMAIL PROTECTED] ]($elem) );
: }
: return @results;
: }
: }
:
: But that still doesn't let me call that like I'd want;
:
: my @r = @array.each :{ $^first * 2 }
: :{ $^second * 9 }
: :{ $^third * 42 };
Which would take some special dispensation like "Multiple anonymous
closures are pushed onto the slurp array if there's no slurp closure."
On the other hand, we've not really specified very well what happens
if you pass two named parameters of the same name, other than saying
the first one binds to the named parameter (if any) and the second
one ends up in the slurpy hash. But what happens to the third one?
An argument could be made for creating a subarray in the hash when
there are multiples, in which case your multiple blocks would
come through as %hash{""}[]. But I hate it that you'd have to
treat a single argument differently.
Maybe there's some way to extend signature syntax similarly to what
we did for [$head, [EMAIL PROTECTED] arguments. There seems to be some kind
of generic problem here with assuming named array arguments are always
passed as a reference to a single array rather than a list of arguments
with the same name. I'd much prefer a general solution than a bandaid
just for blocks.
: The other thing I'm wondering is how to apply adverbs to the results
: of a function, if that's even possible. I believe this is valid:
Adverbs by definition modify verbs, not nouns.
: my $odd = 1... :by(2) # an infinite list of odd numbers
I suppose an adverb can apply itself directly to a postfix operator
like that, given that it still sets up the expectation for an
operator rather than a term.
: But this?
:
: sub odd_numbers([EMAIL PROTECTED] of Pair) {
: return 1...;
: }
: my $odd = odd_numbers :by(2);
:
: Does that pass C 2> as a Pair to the function?
Yes. A term is expected, :by(2) is just a pair.
: Or does it apply the adverb to the result? Maybe I need to do this?
:
: my $odd = (odd_numbers) :by(2);
:
: My head is swimming at this point, so I'd better give it a rest.
That would apply the adverb to the =, which would make anyone's
head swim, especially anyone trying to figure out how to implement
assignment "by 2".
Larry
Re: Revision of A12's lookahead notions
On Fri, Aug 13, 2004 at 09:19:29PM -0400, Uri Guttman wrote: : i have no issue with splurt() being needed to disambiguate. i just : wanted to see your take (this week :) on it as i felt the table was : ambiguous so far. as far as making it a warning, wouldn't that make the : warning space sensitive? :-/ There are some of those in Perl 5 already. Larry
Anonymous Named params (Was Revision of A12's lookahead notions)
> -Original Message-
> 1d) Additional arguments may occur as adverbs *only* if there
> are explicit parens. (Or in the absence of parens they may
> parse as arguments when a term is expected--but then they're
> not adverbs, just named arguments...)
>
> splurt():by{ +$_ } # okay
> splurt 1,2,3 :by{ +$_ } # ILLEGAL (comma rejects the adverb)
> splurt 1,2,3 :{ +$_ } # ILLEGAL (comma rejects the adverb)
> splurt 1,2,3,:{ +$_ } # likely okay (as anonymous named
> param)
> splurt :{ +$_ } # likely okay (as anonymous named
> param)
> splurt { +$_ } # okay (positional param)
> splurt 1,2,3, { +$_ } # okay (positional param)
>
Doesn't the concept of an anonymous named param (in the fourth and fifth
examples above) seem like an oxymoron? If it's anonymous it can't have a
name (or at least we can't know its name). More importantly, what is an
anonymous named param used for?
Also, suppose I have a hash
%foo = {'by' => 1, 'from' => 2};
Would
splurt :%foo;
have the same result as
splurt :by(1) :from(2);
or would I need the braces in this case?
Joe Gottman
Re: Anonymous Named params (Was Revision of A12's lookahead notions)
On Sat, Aug 14, 2004 at 12:32:30AM -0400, Joe Gottman wrote:
:Doesn't the concept of an anonymous named param (in the fourth and fifth
: examples above) seem like an oxymoron? If it's anonymous it can't have a
: name (or at least we can't know its name).
It's anonymous only in the sense that the caller doesn't know that
callee's declared name for the slurpy function, just as when you say
push @foo <== 1,2,3
the caller doesn't know what push calls its slurpy list.
: More importantly, what is an anonymous named param used for?
It's for passing a closure argument without having to put parens
around it. I think that's about all it's good for. Though arguably
it'd be nice to allow a slurpy scalar that lets the PDL folks
write something like
[1..10:(3)]
to mean
[1..10:by(3)]
Except then they'll want to write
[1..10:3]
and then they'll get completely confused when
[1..10:int($y)]
doesn't work. So maybe we force them to say "by".
:Also, suppose I have a hash
: %foo = {'by' => 1, 'from' => 2};
: Would
: splurt :%foo;
: have the same result as
: splurt :by(1) :from(2);
:
: or would I need the braces in this case?
Hmm, I don't know where to begin. First, the braces are really
only intended for anonymous closures, not anonymous hashes. (Though
an argument could be made to allow that usage, which presumably
would map all the internal hash keys to parameter values.)
Next, colon is not a prefix operator, so you can't just put it
in front of %foo like that. Even if you allow for a "null" name,
we don't have adverbs that look like :abc%foo, so :%foo doesn't make
any sense. Plus you're passing it where a term is expected, so it's
not an adverb in any case unless you said
splurt() :%foo
or some such. But if you're gonna pass it where a term is expected,
it's just a list of pairs, and you could say
splurt %foo.pairs
or maybe even just
splurt %foo
presuming the signature of splurt won't confuse that for a scalar
argument. You can do tricks like that because normal argument
processing is pretty sophisticated. Adverbs, on the other hand,
are intended only for introducing single pairs, and extending the
syntax for them indefinitely would be a mistake of the same sort as
allowing people to nest statement modifiers. If you want to get
fancy with named parameters, put 'em in the argument list where
they belong.
That being said, I still wonder whether there ought to be a way
of pattern matching single hash arguments like we do single array
arguments. That is, we already have things like:
sub headtail ([$head, [EMAIL PROTECTED], $num) {...}
which will pattern match a call like
headtail(@array, 1)
so maybe there's some call for
sub headstails ({+$heads, +$tails, *%edges}, $num) {...}
that will pattern match a call like
headstails(%hash, 1);
On the other hand, we don't have a way to name such a parameter
in either the [] or {} case yet, so it's hard enough to relate
it to named parameters, let alone anonymous named parameters...
Larry
