Re: Container model - pictures and questions
On Tue, Aug 09, 2005 at 02:06:58PM +0200, TSa 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. 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/ pgpY6xQwewF3p.pgp Description: PGP signature
Re: Container model - pictures and questions
HaloO, 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. -- $TSa.greeting := "HaloO"; # mind the echo!
Re: Container model - pictures and questions
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. Implementatio
Re: Container model - pictures and questions
On Mon, Aug 08, 2005 at 06:04:51PM +0200, "TSa (Thomas Sandla�)" wrote: > Autrijus Tang wrote: > >If I'm mistaken, please let me know, preferably by suggesting > >new arrangements on the diagram. :-) > > Without judging your mistakes, here are my comments to the > container picture. > > 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!? > 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. > 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 (=). >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. 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. Thanks, /Autrijus/ pgpCZrXZWLfie.pgp Description: PGP signature
Re: Container model - pictures and questions
HaloO, Autrijus Tang wrote: If I'm mistaken, please let me know, preferably by suggesting new arrangements on the diagram. :-) Without judging your mistakes, here are my comments to the container picture. 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. 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. 3) Why is the link from the container labeled with := but the link between the cell and the value with =? 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. -- ::TSa.greeting := "HaloO"; # mind the echo!
Container model - pictures and questions
(Cc'ing p6l, but this feels like a p6c thread...) Greetings. As I'm moving forward with the new PIL runcore, I'm now trying to document my understanding as visual diagrams. The first one is about the compilation cycle: http://pugscode.org/images/simple-compilation.png The second one is about the container model: http://pugscode.org/images/container.png Under this container model, there are two consequences that I'm not very sure about. One is that everything is rebindable: my $a is constant; my $b = 123; $a := $b; $a = 456; # succeeds Another is that the "is IType" form is always untieable: my $a is SomehowTiedScalar; untie($a); # succeeds If I'm mistaken, please let me know, preferably by suggesting new arrangements on the diagram. :-) Thanks, /Autrijus/ pgpyQA92bid1i.pgp Description: PGP signature
