Re: Strange interaction between pairs and named binding
Larry wrote:
: If the Bare code object (including pointy and non-pointy) default their
: parameter types to "Any" (that is, Item|Pair|Junction), then all of
: these would work:
:
: for [1..10].pairs { say(.value) }
: for [1..10].pairs { say($^x.value) }
: for [1..10].pairs -> $x { say($x.value) }
: for 1|2, 3|4 { say(.values) }
: for 1|2, 3|4 { say($^x.values) }
: for 1|2, 3|4 -> $x { say($x.values) }
I dunno. I'm inclined to say that it should default to Item|Pair, and
let people say Any explicitly if they really want to suppress autothreading.
Not surprisingly, I strongly agree with this sentiment! ;-)
Damian
Re: Strange interaction between pairs and named binding
On Tue, Jul 19, 2005 at 12:25:02PM +0800, Autrijus Tang wrote:
: On Mon, Jul 18, 2005 at 03:48:55PM -0700, Brent 'Dax' Royal-Gordon wrote:
: > Autrijus Tang <[EMAIL PROTECTED]> wrote:
: > > This currently works in Pugs:
: > >
: > > for [1..10].pairs -> Pair $x { say $x.value }
: > >
: > > But this does not:
: > >
: > > for [1..10].pairs -> $x { say $x.value }
: > >
: > > Because the ruling that pairs must not be bound to parameters that are
: > > not explicitly declared to handle them. Is this a desirable behaviour?
: >
: > How much violence would be done to the language if we declared that
: > block (i.e. closure with no "sub" keyword) parameters defaulted to
: > Item|Pair, while sub parameters defaulted to plain Item? I can't
: > imagine named arguments are going to be used very often on blocks,
: > which tend to be things like loop bodies...
:
: If the Bare code object (including pointy and non-pointy) default their
: parameter types to "Any" (that is, Item|Pair|Junction), then all of
: these would work:
:
: for [1..10].pairs { say(.value) }
: for [1..10].pairs { say($^x.value) }
: for [1..10].pairs -> $x { say($x.value) }
: for 1|2, 3|4 { say(.values) }
: for 1|2, 3|4 { say($^x.values) }
: for 1|2, 3|4 -> $x { say($x.values) }
I dunno. I'm inclined to say that it should default to Item|Pair, and
let people say Any explicitly if they really want to suppress autothreading.
Otherwise conditionals and switches are going to behave oddly in the
presence of "accidental" junctions.
Alternately we could try to distinguish explicit pairs from generated
pairs, and require explicit pairs (or * marked generated pairs) to
transition to the named zone.
Larry
Re: Strange interaction between pairs and named binding
On Mon, Jul 18, 2005 at 03:48:55PM -0700, Brent 'Dax' Royal-Gordon wrote:
> Autrijus Tang <[EMAIL PROTECTED]> wrote:
> > This currently works in Pugs:
> >
> > for [1..10].pairs -> Pair $x { say $x.value }
> >
> > But this does not:
> >
> > for [1..10].pairs -> $x { say $x.value }
> >
> > Because the ruling that pairs must not be bound to parameters that are
> > not explicitly declared to handle them. Is this a desirable behaviour?
>
> How much violence would be done to the language if we declared that
> block (i.e. closure with no "sub" keyword) parameters defaulted to
> Item|Pair, while sub parameters defaulted to plain Item? I can't
> imagine named arguments are going to be used very often on blocks,
> which tend to be things like loop bodies...
If the Bare code object (including pointy and non-pointy) default their
parameter types to "Any" (that is, Item|Pair|Junction), then all of
these would work:
for [1..10].pairs { say(.value) }
for [1..10].pairs { say($^x.value) }
for [1..10].pairs -> $x { say($x.value) }
for 1|2, 3|4 { say(.values) }
for 1|2, 3|4 { say($^x.values) }
for 1|2, 3|4 -> $x { say($x.values) }
> Right now one of my biggest Perl 6 nits is that the combination of
> subroutines everywhere and the Pair type's special role in subroutine
> dispatch makes Pairs a real pain to work with. This would help to fix
> the problem without creating a new SuperPair type or something
> similarly silly.
Seconded.
Thanks,
/Autrijus/
pgpdiPC1kpuLj.pgp
Description: PGP signature
Re: Strange interaction between pairs and named binding
Autrijus Tang <[EMAIL PROTECTED]> wrote:
> This currently works in Pugs:
>
> for [1..10].pairs -> Pair $x { say $x.value }
>
> But this does not:
>
> for [1..10].pairs -> $x { say $x.value }
>
> Because the ruling that pairs must not be bound to parameters that are
> not explicitly declared to handle them. Is this a desirable behaviour?
How much violence would be done to the language if we declared that
block (i.e. closure with no "sub" keyword) parameters defaulted to
Item|Pair, while sub parameters defaulted to plain Item? I can't
imagine named arguments are going to be used very often on blocks,
which tend to be things like loop bodies...
Right now one of my biggest Perl 6 nits is that the combination of
subroutines everywhere and the Pair type's special role in subroutine
dispatch makes Pairs a real pain to work with. This would help to fix
the problem without creating a new SuperPair type or something
similarly silly.
--
Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]>
Perl and Parrot hacker
Re: Strange interaction between pairs and named binding
On Mon, Jul 18, 2005 at 08:42:24PM +0800, Autrijus Tang wrote:
: This currently works in Pugs:
:
: for [1..10].pairs -> Pair $x { say $x.value }
:
: But this does not:
:
: for [1..10].pairs -> $x { say $x.value }
:
: Because the ruling that pairs must not be bound to parameters that are
: not explicitly declared to handle them. Is this a desirable behaviour?
No, but it's necessary unless we can find some way of breaking the
magical relationship of pairs with named arguments. Even if we came
up with special syntax on the calling end to differentiate the positional
zone from the named zone, it wouldn't help here, since the call syntax
is implicitly buried in the implementation of "for". So we have to
distinguish it on the formal end, and currently Pair is the way to do that.
Larry
Strange interaction between pairs and named binding
This currently works in Pugs:
for [1..10].pairs -> Pair $x { say $x.value }
But this does not:
for [1..10].pairs -> $x { say $x.value }
Because the ruling that pairs must not be bound to parameters that are
not explicitly declared to handle them. Is this a desirable behaviour?
Thanks,
/Autrijus/
pgp5r3rYqcaLb.pgp
Description: PGP signature
