Re: Container model - pictures and questions
TSa
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 level have to provide these
names and so have low-level package authors. Higher-level package authors
start with "real" Perl6 from there-on. The namespace operator :: plays
a prominent role in this! And it's a pitty that there are whitespace
rules for distinguishing it from ( ?? :: ).
BTW, would ( ?? // ) work as a replacement? My idea is that in
($condition ?? $x // $y) the &infix:<??> returns undef without
evaluating $x iff !$condition. This just needs ?? to have higher
precedence than // or not? Complecated expression for $x and $y
might need parens or braces though. But I regard that as a feature.
And I hope $Larry shares that view.
Am I making sense?
--
$TSa.greeting := "HaloO"; # mind the echo!
TSa
Autrijus Tang wrote:
> The first one is about the compilation cycle:
>
> http://pugscode.org/images/simple-compilation.png
Question: where is the namespace in the picture?
I would expect it to be build in parallel to the
syntax tree between parser and compiler. From there
it might be serialized like PIL itself? Or as part
of it? Only the Target Code Emitters might strip
it if the target doesn't need or support it.
Autrijus Tang
> >The first one is about the compilation cycle:
> >
> > http://pugscode.org/images/simple-compilation.png
>
> Question: where is the namespace in the picture?
> I would expect it to be build in parallel to the
> syntax tree between parser and compiler. From there
> it might be serialized like PIL itself? Or as part
> of it? Only the Target Code Emitters might strip
> it if the target doesn't need or support it.
Packages, aka namespaces, are mutable pointers from names to pads.
They are emitted as part of PIL structure.
Also, thanks for the earlier suggestion about modeling container types
as parametric types; it's indeed a valid suggestion and
I'll try to use that idea in my current prototype. Will write more
when I get the automatic insertion of coercion statements working.
Thanks,
/Autrijus/