Re: Elimination of Item|Pair and Any|Junction
HaloO, Autrijus Tang wrote: 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. Well I would make all types predicate based. The isa relation of an object to the class it was instanciated from is just one amongst many others like doing a role or object structure. And the inheritance hierarchy is mostly irrelevant for typing an object. This is one of the difficulties I have with the metric MMD which relies completely on the count of class derivation levels. I currently have the following model in mind. The compiler collects type information from so-called special forms and stores it in a strictly tree shaped repository called the name space. User code can query this structure by means of the :: forms. The type lattice is then build at CHECK time on top of or from this information. In particular I don't make a distintion between subtype, role, class, sub or method special forms. This implies that where clauses are restricted in the contructs allowed in them and the referential environment accessible to them. 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. :-) The Scala type hierarchy splits from the Any root into the two realms of value types and referential types in good tradition with Java. This split is located in my type lattice below the $Item type where \Ref, Value, Undef, Inf and Junction lie nicely parallel to each other. -- TSa
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
> 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 I misread "mutable" as "mumble" and thought they'd been stumped for a good name too. Brad -- Tether even a roasted chicken. -- Hagakure
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(:literal);
> 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
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(:literal); 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 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 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
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
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
At 10:32 PM + 7/27/05, David Formosa \(aka ? the Platypus\) wrote:
On Wed, 27 Jul 2005 12:17:52 -0700, Mark A. Biggar <[EMAIL PROTECTED]> 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
Re: Elimination of Item|Pair and Any|Junction
On Wed, 27 Jul 2005 12:17:52 -0700, Mark A. Biggar <[EMAIL PROTECTED]> 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.
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 will fit to Any via autoboxing. Thanks, /Autrijus/ pgpQPssdL4iZm.pgp Description: PGP signature
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
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
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 09:12:00AM -0700, Larry Wall wrote: > Yes. The only thing I don't like about it is that any() isn't an Any. > - 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
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 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
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 ]
{
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 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
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 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
