Re: Elimination of Item|Pair and Any|Junction
Autrijus Tang [EMAIL PROTECTED] writes:
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
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.
Re: Elimination of Item|Pair and Any|Junction
Larry Wall wrote:
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.)
Sorry, here's the patch:
: Code @Array %Hash $Item
: | // |
with: | TupleRecord |
invocant(s) : ||
:/ \__ ___|_
|: | |\|| | |
.Method : Sub Block |Value Inf Undef Junction
/|: |\ | |
/ |: | \Ref[Code]|
Rule |: | Macro|
|:_/|__/|\___
|: | | | | | |
Multi : | ~Str +Num \Ref :Pair /Match/
Now the Junction is nicely constraint with the upper bound Item (less
specific) and a lower bound Value (more specific). This also reads
nice if you want to (explicitly) allow both:
sub ( Value|Junction $val_junc )
What sub ( $any ) should default to, I don't know. My $Item indicates
Item, but could also be $Value. Or unspecific $(Item|Value).
--
$TSa.greeting := HaloO; # mind the echo!
Re: Elimination of Item|Pair and Any|Junction
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 [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: /me tips over a cow: neeyah!! pgpvvnhW5imFv.pgp Description: PGP signature
Re: Elimination of Item|Pair and Any|Junction
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(:literalpair); foo(*%nameds); foo(*$pair); foo([EMAIL PROTECTED]); That will mean that foo($pair) will always be positional. Thanks, /Autrijus/ pgpcAv844aT1u.pgp Description: PGP signature
Re: Elimination of Item|Pair and Any|Junction
On Fri, Jul 29, 2005 at 05:59:43AM +0800, Autrijus Tang wrote:
I can see marking things explicitly for named bindings:
foo(:literalpair);
foo(*%nameds);
foo(*$pair);
foo([EMAIL PROTECTED]);
Er, sorry, the last one should be
foo(*%{ hash @list_of_pairs });
Thanks,
/Autrijus/
pgpBLMrCD5fBT.pgp
Description: PGP signature
Elimination of Item|Pair and Any|Junction
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/
pgpbsmHzHG4yc.pgp
Description: PGP signature
Re: Elimination of Item|Pair and Any|Junction
On Wed, Jul 27, 2005 at 08:01:25PM +0800, Autrijus Tang wrote:
: 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?
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
Re: Elimination of Item|Pair and Any|Junction
Larry~
On 7/27/05, Larry Wall [EMAIL PROTECTED] wrote:
On Wed, Jul 27, 2005 at 08:01:25PM +0800, Autrijus Tang wrote:
: 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?
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].
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
Re: Elimination of Item|Pair and Any|Junction
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/ pgpO521iJVLcV.pgp Description: PGP signature
Re: Elimination of Item|Pair and Any|Junction
HaloO,
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.
Since we are in type hierachies these days, here's my from ::Any
towards ::All version. The bottom part where everything finds
together is missing for this installment.
::Any
... | ..
___:_|_:static type :
| : | : | | = context :
Package: | : Void Bool :
| : | :.
Module: |
___|___: |
| | : |
Class Grammar : |
|___| : |
| : |
Role : Object
: |
: | || |
: Code @Array %Hash $Item
: | // |
with: | TupleRecord |
invocant(s) : ||
:/ \__ __|_
|: | |\ / || | | |
.Method : Sub Block | | Inf Undef Match Junction
/|: |\ | |
/ |: | \Ref[Code]|
Rule |: | Macro|
|:_/|__/|\
|: | | | | |
Multi : | ~Str +Num \Ref :Pair
..: | | | |\|
| |Int| \ |
___/| | | | Entry[::T where T.does(Hash)]
| | | |/|\|
*List Pipe =Iterator Enum ?Bit Pos[::T where T.does(Str|Array)]
|\___
| | |
**Eager Lazy Ref[Array|Hash]
any() == lub( all --- any ) == glb( any -- all ) lesser -- greater
all() == glb( all --- any ) == lub( any -- all )
Some operators and prefixes are added in to show their
relation to the corresponding type. I hope it looks familiar.
Here is some pseudo code that describes a bare minimum data layout
required to support the respective types.
type Item[::T]
{
has $.value of T;
}
type Pair[::T]
{
has $.key;
has $.value of T;
}
type Tuple[::T where T does lub( @.values )] # lub = least upper bound
{
has @.values of T;
has $.value ::= @.values; # auto-enreference for Item subtyping
has T $.head ::= @.values[0];
has T $.tail ::= @.values[-1];
}
type Record[::T where T does lub( @.values )]
{
has @.keys;
has @.values of Pair[T];
has @.pairs ::= { zip @.keys, @.values };
has $.value ::= @.pairs;
}
type Code
{
has %.MY;# lexical scratchpad
has .block;
has $.value ::= { use %.MY; .block() }; # coderef literal
}
type Junction[::T where enum any all one none]
{
has @.values;
has Junction $.value ::= { @.values as Junction[T] };
has .evaluate ::= ::JUNCTION_MAGIC; # what's the exact type of this?
}
--
$TSa.greeting := HaloO; # mind the echo!
Re: Elimination of Item|Pair and Any|Junction
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
Re: Elimination of Item|Pair and Any|Junction
Larry Wall wrote:
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.)
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?
--
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Re: Elimination of Item|Pair and Any|Junction
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/ pgplBqGItv0yM.pgp Description: PGP signature
Re: Elimination of Item|Pair and Any|Junction
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
Re: Elimination of Item|Pair and Any|Junction
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
Re: Elimination of Item|Pair and Any|Junction
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/ pgpQPssdL4iZm.pgp Description: PGP signature
