HaloO,
Autrijus Tang wrote:
1) I would move the ::name to the Pad level. The idea is
that ::name is some less specific supertype of the
Fantastique Four ($@%) if more than one of them exists
on the container level.
Please annotate this idea with the code. You mean:
my $a = 3;
my @a = 1..10;
And somehow ::a is the supertype of the two!?
Yes. I should somewhat behave like any($a,@a) without flattening @a.
any($a,@a).does(Item) # true
any($a,@a).does(Array) # true
Another idea of mine is to think of $a beeing the short form of
Item::a and @a for Array::a. Or in yet another way the sigils
are not really part of the name but a split into four sublevels
available everywhere. This might nicely play together with other
languages on the Parrot level. For example sub foo {...} enters
the name 'foo' in the Code branch of the immediately surrounding
namespace. Within ::foo one can find information about lexical
variable types like ::foo::MY::Item::a, or ::foo::ENTER, ::foo::LEAVE,
::foo::BEGIN etc. This information is retrieved when the referential
environment of a foo invocation shall be bound. The signature might
also be a subnamespace ::foo::SIGNATURE::Item::x, etc. Positional
parameter types could e.g. be available as ::foo::SIGNATURE::1,
::foo::SIGNATURE::2, etc.
Here it would be nice to have relaxed whitespace constraints on ::,
see below. Otherwise things like ::foo::SIGNATURE::Item of Int::x might
work in PIL only. And I think inline PIL should be available to
low-level tasks. Operator ::= falls in that category as well. Not
to mention conditional lookup with ?? :)
2) I don't understand why you need two levels of indirection
firstly the container and then the cell. Not to mention
the third one to the tied thingy.
Because assignment (=), binding (:=) and tie are operating on different
levels, the same way Perl 5 typeglobs and tie works.
Yeah, but Perl5 has no explicit type system. It treats Foo::Bar
as a string that is only structured by convention. Perl6 has a
full-blown, hierarchical namespace and barewords are looked up
there. And the three operations =, := and .tie are found there
as well. They are Code subtypes and---citing the
::Matrix::Reloaded::KeyMaker---do what they are meant to do.
3) Why is the link from the container labeled with :=
but the link between the cell and the value with =?
Because you change container-cell relationship with binding (:=) and
cell-value relationship with assignment (=).
OK, that's a nice mnemonic. But it need not be implemented
that way---in particular after optimization.
I would consistently dispatch *all* operators including
:=, = and =:=. Preferably at compile/check time. Container
types are then on the same level as any other parametric
type. This naturally explains why your is IType can
be changed like underwear. For the type system it is just
another mutator. Whatever it does to the tied object takes
effect only by changing the type and hence the methods which
are applicable.
Again, please annotate your idea with code. For scalars, I cannot see
how and assignment are supposed to be dispatched to the same
underlying object. It seems to me that:
$x := $y
and
$x = $y
are manipulating two different entities, as I have shown in the drawing.
First of all there are *two* different multi-methods/operators. Usually they
have more than one implementation each. Also the two expressions $x and $y
can be typed. The very least that is known about them is that they are
Items. The compiler than produces code that dispatches to
infix:{'='}:(Item,Item) and infix:{':='}:(Item,Item) repectively.
A generic implementation of = might just end up as:
::Item::x::STORE( ::Item::y::FETCH() );
OTOH, $x := $y hints to the compiler that from here on the user is
not interested in the thing $x represented until now and use only
::Item::y where $x is in the code. If $x is located in a non-transient
position in the namespace it shall represent some kind of link from
there to where $y refers. This might end up as:
::Item::x::LINK( ::Item::y::FETCH() );
I would also like to know how the perl 5 idea of tie can be explained
with coercing the variable into another parametric type. It seems to
me that tie() is a runtime operation that associates a cell with an
object, and the concrete object then intercepts access into that cell.
Well, yes I think it's a multi method with two invocants a cell and an
object in your picture. What it does to these two is up to the one
implementing the method, as usual ;)
And the cell and the object might have an opinion to what extent
they cooperate 8)
Of course at one level there has to exist a low-level protocol that
Perl6 is compiled down to. And I thought this is what PIL is? So
essentially it boils down to presribing some names like STORE, FETCH,
ENTER, LEAVE etc. and using them in some least specific operator
implementations. Implementations on the VM
