Strange interaction between pairs and named binding

1 view
Skip to first unread message

Autrijus Tang

unread,
Jul 18, 2005, 8:42:24 AM7/18/05
to perl6-l...@perl.org
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/

Larry Wall

unread,
Jul 18, 2005, 3:46:46 PM7/18/05
to perl6-l...@perl.org
On Mon, Jul 18, 2005 at 08:42:24PM +0800, Autrijus Tang wrote:
: This currently works in Pugs:

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

Brent 'Dax' Royal-Gordon

unread,
Jul 18, 2005, 6:48:55 PM7/18/05
to Autrijus Tang, perl6-l...@perl.org

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 <br...@brentdax.com>
Perl and Parrot hacker

Autrijus Tang

unread,
Jul 19, 2005, 12:25:02 AM7/19/05
to br...@brentdax.com, Autrijus Tang, perl6-l...@perl.org
On Mon, Jul 18, 2005 at 03:48:55PM -0700, Brent 'Dax' Royal-Gordon wrote:
> Autrijus Tang <autr...@autrijus.org> 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/

Larry Wall

unread,
Jul 22, 2005, 6:40:34 PM7/22/05
to perl6-l...@perl.org
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 <autr...@autrijus.org> 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

Damian Conway

unread,
Jul 22, 2005, 9:24:46 PM7/22/05
to Larry Wall, perl6-l...@perl.org
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

Autrijus Tang

unread,
Jul 27, 2005, 8:01:25 AM7/27/05
to perl6-l...@perl.org
On Fri, Jul 22, 2005 at 03:40:34PM -0700, Larry Wall wrote:
> 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.

Okay. However, in that view, I suspect many builtins will be defined on
Item|Pair, for example &perl, &clone, &id, as well as various coercion
builtins. Considering that builtins are Code objects but not Routines,
maybe they, too, should default to Item|Pair -- except the ones that
operates on junctions, of course.

This leads me to think that maybe users don't really need to write down
the two junctive types, under the hierarchy below:

- Object
- Any
- Item
- ...pretty much everything
- Pair
- Junction
- num, int, str...

Since junctions are still boxed objects, having the Object type to
effectively mean Any|Junction seems natural ("everything is an object").

Also, since Any unifies Item and Pair, the rule for implicit types of
argument becomes:

sub ($x) { } # Item $x
-> $x { } # Any $x - i.e. Item|Pair but not Junction
{ $^x } # Any $x - i.e. Item|Pair but not Junction

Does this sound sane?

Thanks,
/Autrijus/

Autrijus Tang

unread,
Jul 27, 2005, 12:26:27 PM7/27/05
to Matt Fowles, perl6-l...@perl.org
On Wed, Jul 27, 2005 at 12:19:10PM -0400, Matt Fowles wrote:
> While we are talking about words... I dislike having Object encompass
> Juction. I get the feeling that some people will write functions that
> take Objects and not expect Junctions to slip in. I suppose that
> could be one of those hurdles that developers just have to jump, but
> it doesn't feel like it should be.

Er, but Junctions take methods, the same way Objects do, so if there is
an Object in the type hierarchy, Junction probably belongs to it.

However we can tone down the ordinariness of Object so people will be
less inclined to use it. "Boxed"?

Thanks,
/Autrijus/

Larry Wall

unread,
Jul 27, 2005, 12:12:00 PM7/27/05
to perl6-l...@perl.org
On Wed, Jul 27, 2005 at 08:01:25PM +0800, Autrijus Tang wrote:

Yes. The only thing I don't like about it is that any() isn't an Any.
Maybe we should rename Any to Atom. Then maybe swap Item with Atom,
since in colloquial English you can say "that pair of people are
an item." That would give us:

- Object
- Item
- Atom


- ...pretty much everything
- Pair
- Junction
- num, int, str...

which nicely distinguishes Item from Junction. On the other hand,
I actually kinda dislike the word "Atom" for common use (too much
exposure to Lisp, I guess), so maybe we just want

- Object
- Mumble


- Item
- ...pretty much everything
- Pair
- Junction
- num, int, str...

where Mumble is something like Atom/NonJunction/Unit/Scalar/[your ad here].

Larry

Matt Fowles

unread,
Jul 27, 2005, 12:19:10 PM7/27/05
to perl6-l...@perl.org
Larry~

While we are talking about words... I dislike having Object encompass


Juction. I get the feeling that some people will write functions that
take Objects and not expect Junctions to slip in. I suppose that
could be one of those hurdles that developers just have to jump, but
it doesn't feel like it should be.

Matt
--
"Computer Science is merely the post-Turing Decline of Formal Systems Theory."
-Stan Kelly-Bootle, The Devil's DP Dictionary

Larry Wall

unread,
Jul 27, 2005, 2:35:22 PM7/27/05
to perl6-l...@perl.org
On Wed, Jul 27, 2005 at 06:28:22PM +0200, "TSa (Thomas Sandlaß)" wrote:
: Since we are in type hierachies these days, here's my from ::Any
: towards ::All version.

That's pretty, but if you don't move Junction upward, you haven't
really addressed the question Autrijus is asking. We're looking
for a simple type name that means none(Junction) for use as the
default type of the $x parameter to -> $x {...}. Whatever we call
it, this type/class/role/subtype has to admit Item and Pair objects
but not Junctions. (And if that's the wrong way to think about it,
please tell us why.)

Larry

Mark A. Biggar

unread,
Jul 27, 2005, 3:17:52 PM7/27/05
to Larry Wall, perl6-l...@perl.org

Suggestions:

Definite
Singelton (but that may mean no pairs, oops)
Solid
Settled
NonJunctive (yuck)
Terminal
NonThreaded (yuck)
Simple (but that could exclude arrays and hashs)]
Basic

Interesting question: are junctions infectious, are class object that
include a member with ajunction type also junctions?


--
ma...@biggar.org
mark.a...@comcast.net

Autrijus Tang

unread,
Jul 27, 2005, 3:55:55 PM7/27/05
to perl6-l...@perl.org
On Wed, Jul 27, 2005 at 09:12:00AM -0700, Larry Wall wrote:
> Yes. The only thing I don't like about it is that any() isn't an Any.

<snip>

> - Object
> - Mumble
> - Item
> - ...pretty much everything
> - Pair
> - Junction
> - num, int, str...

Hrm. I thought the original motivation of forcing people to write

Any|Junction

was precisely to discourage people from accidentally write

sub foo (Any $x)

and have $x accept a Junction. In other words, any() should not be of
type Any. Hence it still feels natural for me that Any occurs at the
position of Mumble.

Thanks,
/Autrijus/

Larry Wall

unread,
Jul 27, 2005, 4:25:43 PM7/27/05
to perl6-l...@perl.org
On Wed, Jul 27, 2005 at 12:19:10PM -0400, Matt Fowles wrote:
: While we are talking about words... I dislike having Object encompass

: Juction. I get the feeling that some people will write functions that
: take Objects and not expect Junctions to slip in. I suppose that
: could be one of those hurdles that developers just have to jump, but
: it doesn't feel like it should be.

In which case

- Any
- Object
- Item


- ...pretty much everything
- Pair
- Junction
- num, int, str...

would be a little more like Thomas's type lattice. (Though I expect he'd
treat the value types as constrained subtypes of Num, Int, Str, etc.)

It seems stupid to split Object into just two things. But maybe
there are other magical beasties like Pair that go alongside Pair,
such as ordinary lazily bound argument lists before they are bound
to a particular signature, or semicolons/pipes before it's determined
if the signature is semicolon-sensitive. Basically, anything that's
magical to the binder goes on that level, and according to the above
would be an Object but not an Item.

However we do it, we can only aim for Least Surprise, since No Surprise
is not really attainable here.

Larry

Darren Duncan

unread,
Jul 27, 2005, 4:25:26 PM7/27/05
to Larry Wall, perl6-l...@perl.org
At 9:12 AM -0700 7/27/05, Larry Wall wrote:
>Yes. The only thing I don't like about it is that any() isn't an Any.
>Maybe we should rename Any to Atom. Then maybe swap Item with Atom,
>since in colloquial English you can say "that pair of people are
>an item." That would give us:
>
> - Object
> - Item
> - Atom
> - ...pretty much everything
> - Pair
> - Junction
> - num, int, str...
>
>which nicely distinguishes Item from Junction. On the other hand,
>I actually kinda dislike the word "Atom" for common use (too much
>exposure to Lisp, I guess), so maybe we just want
>
> - Object
> - Mumble
> - Item
> - ...pretty much everything
> - Pair
> - Junction
> - num, int, str...
>
>where Mumble is something like Atom/NonJunction/Unit/Scalar/[your ad here].

At 11:35 AM -0700 7/27/05, Larry Wall wrote:
>We're looking
>for a simple type name that means none(Junction) for use as the
>default type of the $x parameter to -> $x {...}. Whatever we call
>it, this type/class/role/subtype has to admit Item and Pair objects
>but not Junctions. (And if that's the wrong way to think about it,
>please tell us why.)

Between what you've said, I prefer the top diagram myself. Where
<something> and Pair are each Item. Item seems more generic, and is
what one often calls a constituent of a list being iterated through.
So the $x parameter to -> $x {...} should be called Item.

So then the question is what to replace Atom with:

- Object
- Item
- Mumble


- ...pretty much everything
- Pair
- Junction
- num, int, str...

In my brainstorming, I found it is a lot easier to come up with words
that mean single than non-junction. So working from that perspective
...

Why don't we just call it a Single?

- Object
- Item
- Single


- ...pretty much everything
- Pair
- Junction
- num, int, str...

The noun Single is common in speech, unambiguous in meaning, and
looks visually distinct from all the other types. It is often used
side by side in speech, such as "she is a single" and "they are a
pair". Also, Single doesn't suggest being indivisible like Atom does.

I also vote against the use of Scalar there, since Scalar seems too
specific. Likewise with NonJunction, if we can help it, because it
looks messy.

-- Darren Duncan

Autrijus Tang

unread,
Jul 27, 2005, 5:31:46 PM7/27/05
to Autrijus Tang, perl6-l...@perl.org
On Thu, Jul 28, 2005 at 03:55:55AM +0800, Autrijus Tang wrote:
> Hrm. I thought the original motivation of forcing people to write
>
> Any|Junction
>
> was precisely to discourage people from accidentally write
>
> sub foo (Any $x)
>
> and have $x accept a Junction. In other words, any() should not be of
> type Any. Hence it still feels natural for me that Any occurs at the
> position of Mumble.

FWIW, if Any is to be ruled to be the top type and includes Junction,
then I support Darren's proposal of "Single", and maybe the Object type
can be simply eliminated to Any:

Any - Item - Single
- Pair
- Junction
- int, num, str

This also means that <int num str> will fit to Any via autoboxing.

Thanks,
/Autrijus/

David Formosa )

unread,
Jul 27, 2005, 6:32:33 PM7/27/05
to perl6-l...@perl.org
On Wed, 27 Jul 2005 12:17:52 -0700, Mark A. Biggar <ma...@biggar.org> wrote:
> Larry Wall wrote:

[...]

>> Whatever we call
>> it, this type/class/role/subtype has to admit Item and Pair objects
>> but not Junctions. (And if that's the wrong way to think about it,
>> please tell us why.)
>
> Suggestions:
>
> Definite

Collapsed

--
Please excuse my spelling as I suffer from agraphia. See
http://dformosa.zeta.org.au/~dformosa/Spelling.html to find out more.
Free the Memes.

Darren Duncan

unread,
Jul 27, 2005, 8:26:40 PM7/27/05
to perl6-l...@perl.org
At 10:32 PM +0000 7/27/05, David Formosa \(aka ? the Platypus\) wrote:
>On Wed, 27 Jul 2005 12:17:52 -0700, Mark A. Biggar <ma...@biggar.org> wrote:
>> Larry Wall wrote:
>
>[...]
>
>>> Whatever we call
>>> it, this type/class/role/subtype has to admit Item and Pair objects
>>> but not Junctions. (And if that's the wrong way to think about it,
>>> please tell us why.)
>>
>> Suggestions:
>>
>> Definite
>
>Collapsed

Assuming that a Junction represents a quantum superposition of
values, then I agree that either Definite or Collapsed would be a
good non-Junction name.

It fits in with the same theme, and sounds much more like a Junction
complement than an Item or Single or Pair or whatever.

So it might be reasonable to have:

Any - Definite - Single
- Pair
- Junction

Further in this discussion, I don't see why it isn't reasonable for
the $x parameter to -> $x {...} to be a Junction. Maybe the $x
should just be an Any and be done with it.

-- Darren Duncan

Yuval Kogman

unread,
Jul 28, 2005, 10:13:58 AM7/28/05
to Autrijus Tang, Matt Fowles, perl6-l...@perl.org
On Thu, Jul 28, 2005 at 00:26:27 +0800, Autrijus Tang wrote:
> Er, but Junctions take methods, the same way Objects do, so if there is
> an Object in the type hierarchy, Junction probably belongs to it.

Maybe there is a role called 'Junctive'? I think junctions are
orthogonal to other types, except when people try to deal with them
explicitly... The all encompassing type is not really a type, but
more of a shortcut.

My take:

Any
Object
Item
Atom
...
Pair
Junction
int, str, ...

where any of these can also 'do' Junctive.

--
() Yuval Kogman <nothi...@woobling.org> 0xEBD27418 perl hacker &
/\ kung foo master: /me tips over a cow: neeyah!!!!!!!!!!!!!!!!!!!!!!

Larry Wall

unread,
Jul 28, 2005, 12:27:00 PM7/28/05
to perl6-l...@perl.org
On Thu, Jul 28, 2005 at 05:31:46AM +0800, Autrijus Tang wrote:

: On Thu, Jul 28, 2005 at 03:55:55AM +0800, Autrijus Tang wrote:
: > Hrm. I thought the original motivation of forcing people to write
: >
: > Any|Junction
: >
: > was precisely to discourage people from accidentally write
: >
: > sub foo (Any $x)
: >
: > and have $x accept a Junction. In other words, any() should not be of
: > type Any. Hence it still feels natural for me that Any occurs at the
: > position of Mumble.
:
: FWIW, if Any is to be ruled to be the top type and includes Junction,
: then I support Darren's proposal of "Single", and maybe the Object type
: can be simply eliminated to Any:

There is something to be said for avoiding "Object" as a word with
too much existing baggage from other cultures.

: Any - Item - Single


: - Pair
: - Junction
: - int, num, str
:
: This also means that <int num str> will fit to Any via autoboxing.

Which makes "Any" mean "anything that can act like an Object" rather
than the stricter "anything that 'isa' Object". Hmm...

Item could take over the 'isa' role of Object, I suppose. That does
imply that Junctions (and any other syntactic lazinesses we throw into
that slot) aren't really objects. Maybe we can deal with that.

Or maybe Any really does mean "Object" and we're just viewing our
hierarchy too strictly if we make every relationship "isa". That's one
thing that neither this formulation nor Thomas's are making very
clear--which type relations are really subclassing, which are role
composition, and which are subtype constraints. Certainly some of
Thomas's recombining relations should be viewed as role composition
rather than MI. And you can view the whole autoboxing issue as an
implementation detail of constrained subtypes, where the constraint
happens to be a restriction on the set of values that can fit into
a particular representation.

And I'm still not entirely sure I believe the "not-yet-bound-ness" of
Pairs is all that different from the not-yet-bound-ness of Junctions
to the extent that a different type level is warranted. I guess I
still think there ought to be a way of marking Pairs on the call end
as to whether they're intended for named args or not, without warping
the whole top-level type system to that end.

Larry

Autrijus Tang

unread,
Jul 28, 2005, 5:59:43 PM7/28/05
to perl6-l...@perl.org
On Thu, Jul 28, 2005 at 09:27:00AM -0700, Larry Wall wrote:
> Or maybe Any really does mean "Object" and we're just viewing our
> hierarchy too strictly if we make every relationship "isa". That's one
> thing that neither this formulation nor Thomas's are making very
> clear--which type relations are really subclassing, which are role
> composition, and which are subtype constraints.

FWIW, I've been reading up on Scala's formulation of trait/class/delegation
hierarchy, and I feel a bit like flipping through a puzzle book to look
at the hints, if not answers. :-)

http://scala.epfl.ch/docu/files/api/index.html

> And I'm still not entirely sure I believe the "not-yet-bound-ness" of
> Pairs is all that different from the not-yet-bound-ness of Junctions
> to the extent that a different type level is warranted.

Junctive autothreading are "outside" bindings -- they can be viewed as a
two-phase exception handling from parameter type mismatches that fires
away more function applications. Pairs on the other hand are bound
normally; they just have a preferred zone unless overriden by the
parameter signature; this resolution is strictly within the same
one-step binding. I think there may be more types to come that has its
preferred binding semantic, than outside-the-box devices like Junctions.

> I guess I still think there ought to be a way of marking Pairs on the
> call end as to whether they're intended for named args or not, without
> warping the whole top-level type system to that end.

I can see marking things explicitly for named bindings:

foo(:literal<pair>);
foo(*%nameds);
foo(*$pair);
foo(*%{*@list_of_pairs});

That will mean that foo($pair) will always be positional.

Thanks,
/Autrijus/

Autrijus Tang

unread,
Jul 28, 2005, 6:01:58 PM7/28/05
to Autrijus Tang, perl6-l...@perl.org
On Fri, Jul 29, 2005 at 05:59:43AM +0800, Autrijus Tang wrote:
> I can see marking things explicitly for named bindings:
>
> foo(:literal<pair>);
> foo(*%nameds);
> foo(*$pair);
> foo(*%{*@list_of_pairs});

Er, sorry, the last one should be

foo(*%{ hash @list_of_pairs });

Thanks,
/Autrijus/

Piers Cawley

unread,
Aug 3, 2005, 6:30:17 AM8/3/05
to Autrijus Tang, perl6-l...@perl.org
Autrijus Tang <autr...@autrijus.org> writes:

Maybe there's a case for introducing Bundle types, akin to CPAN bundles. These
would be types only in the very losest sense, that could be used in function
prototypes to stand for particular bundles of types. So instead of Any being in
the class hierarchy where you propose it'd be a bundle that expanded to the
equivalent of doing:

any(Object.all_subclasses.grep -> $class { !$class.does(Junction) })

That way we get to arrange the class hierarchy in the way that makes the most
sense conceptually, but slice still slice it appropriately for Type
specifiers.

Just a thought.

Reply all
Reply to author
Forward
0 new messages