Container model - pictures and questions

[Autrijus Tang]

(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/

[Matt Fowles]

Autrijus~

On 8/6/05, Autrijus Tang <autr...@autrijus.org> wrote:
> (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
>

The pictures are pretty and the compilation one makes a great deal of
sense, but I must admit to being enitrely confused by the container
one. I think part of the problem is that I don't have a good footing
from which to understand it. Is there somewhere I can look for a
gentle explanation of the whole container/tied/untied thing?

Thanks,
Matt
--
"Computer Science is merely the post-Turing Decline of Formal Systems Theory."
-Stan Kelly-Bootle, The Devil's DP Dictionary

[Autrijus Tang]

On Sat, Aug 06, 2005 at 12:43:13PM -0400, Matt Fowles wrote:
> The pictures are pretty and the compilation one makes a great deal of
> sense, but I must admit to being enitrely confused by the container
> one. I think part of the problem is that I don't have a good footing
> from which to understand it. Is there somewhere I can look for a
> gentle explanation of the whole container/tied/untied thing?

Hm, I'm afraid there are not much material on this beyond the Synopses,
so I'll try to describe that picture a bit.

First off, all the lines you see are "has-a" relationships. To wit:

Pad has-a Scalar Container that you can look up with "$name".

my $name;

The Container either has-a mutable cell, or has-a constant cell.

my $mut = 3;
my $con := 3;

Use ":=" to change the cell inside a container:

my $x = 3;
my $y = 4;
my $z = 5;
$x := $y; # $x and $y now contain the same cell
$x := $z; # not anymore; $x now shares the cell with $z

Each cell has a Id. Use "=:=" to check whether two containers have
cells of the same Id:

$x =:= $y; # false
$x =:= $z; # true

Mutable cells has-a mutable scalar value. Use "=" to change its value:

$mut = 5; # works

Constant cells has-a immutable scalar value. You cannot change it:

$con = 6; # error

Each cell is declared to be "is Tieable" or not tiable when it was
allocated; you cannot change tieableness at runtime.

my $nvar;
my $tvar is Tieable;

Tieable cells may be tied or untied. Use "tie" to tie a tieable cell:

tie($tvar, SomeClass, some_param => 1);

Non-tieable cells may not be tied. However, "untie" always works:

untie($tvar); # works
untie($nvar); # no-op

That's about it. :-) Hopefully my two questions will make more sense
to you now...

Thanks,
/Autrijus/

[Nathan Gray]

On Sun, Aug 07, 2005 at 12:55:53AM +0800, Autrijus Tang wrote:
> Hm, I'm afraid there are not much material on this beyond the Synopses,
> so I'll try to describe that picture a bit.
>

...

>
> That's about it. :-) Hopefully my two questions will make more sense
> to you now...

Very nice description. Thank you. I understand the diagram much better
now.

-kolibrie

[Autrijus Tang]

On Sun, Aug 07, 2005 at 10:58:01PM +0100, Tim Bunce wrote:
> > The Container either has-a mutable cell, or has-a constant cell.
> >
> > my $mut = 3;
> > my $con := 3;
> >
> > Use ":=" to change the cell inside a container:
>

> How about:
>
> Use ":=" to change the container to have a different cell.

That is correct. Or "replace the cell".

> > Each cell has a Id. Use "=:=" to check whether two containers have
> > cells of the same Id:
> >
> > $x =:= $y; # false
> > $x =:= $z; # true
>

> It's hard to imagine two "containers" both containing the same cell.
> The cell isn't really in two places at the same time.
>
> What's missing from the description is that there's some form of
> 'pointer' from a container to the cell it currently contains.
> (I'm trying to avoid using the term reference.)

Yes. The mutable has-a relationships are maintained with pointers.
I think the legend needs to be updated to reflect this fact.

> The description of the container model might benefit from making that
> pointer more explicit. It would help to clarify the action of the :=
> operator. (And =:= ?)

Right. =:= is first retrieving the cells by chasing the pointer,
read the cell's id, and then comparing them.

> Please correct me if I'm laboring under too much perl5 baggage or
> confused in other ways.

No, your understanding is entirely sound. The Container model is
basically a renormalized "glob" concept to apply also to lexical pads,
but with only one way to dereference the glob (i.e. the container),
instead of seven ways.

Hence, it looks like that it is indeed possible to rebind a variable
declared "is constant" to something mutable, just as this Perl 5
snippet does:

our ($a, $b);
*a = \3;
$b = 4;
*a = *b;
print $a; # 4

Compare with Perl 6:

my $a := 3;
my $b = 4;
$a := $b;
print $a; # 4

Thanks,
/Autrijus/

[Tim Bunce]

[I'm going to be a little pedantic here because I think it's worth it
given the need for clarity.]

On Sun, Aug 07, 2005 at 12:55:53AM +0800, Autrijus Tang wrote:

> On Sat, Aug 06, 2005 at 12:43:13PM -0400, Matt Fowles wrote:
> > The pictures are pretty and the compilation one makes a great deal of
> > sense, but I must admit to being enitrely confused by the container
> > one. I think part of the problem is that I don't have a good footing
> > from which to understand it. Is there somewhere I can look for a
> > gentle explanation of the whole container/tied/untied thing?
>
> Hm, I'm afraid there are not much material on this beyond the Synopses,
> so I'll try to describe that picture a bit.
>
> First off, all the lines you see are "has-a" relationships. To wit:
>
> Pad has-a Scalar Container that you can look up with "$name".
>
> my $name;
>
> The Container either has-a mutable cell, or has-a constant cell.
>
> my $mut = 3;
> my $con := 3;
>
> Use ":=" to change the cell inside a container:

How about:

Use ":=" to change the container to have a different cell.

because "change the cell" could be misleading. The cell itself
isn't modified.

This is (I presume) essentially the same this Perl 5 snippet:

$mut = 3;
*mut = \3; # change the SCALAR slot in the GLOB called 'mut'

> my $x = 3;
> my $y = 4;
> my $z = 5;
> $x := $y; # $x and $y now contain the same cell
> $x := $z; # not anymore; $x now shares the cell with $z
>
> Each cell has a Id. Use "=:=" to check whether two containers have
> cells of the same Id:
>
> $x =:= $y; # false
> $x =:= $z; # true

It's hard to imagine two "containers" both containing the same cell.

The cell isn't really in two places at the same time.

What's missing from the description is that there's some form of
'pointer' from a container to the cell it currently contains.
(I'm trying to avoid using the term reference.)

The description of the container model might benefit from making that

pointer more explicit. It would help to clarify the action of the :=
operator. (And =:= ?)

Please correct me if I'm laboring under too much perl5 baggage or
confused in other ways.

Tim.

[Autrijus Tang]

On Sun, Aug 07, 2005 at 10:58:01PM +0100, Tim Bunce wrote:

> What's missing from the description is that there's some form of
> 'pointer' from a container to the cell it currently contains.
> (I'm trying to avoid using the term reference.)

I have updated the picture. It it marked as "(v2)":

http://pugscode.org/images/container.png

The read-only lookups are now in italic, and rw pointers are marked
as "Pointer" in the legend. Also added the "tied" accessor to the
underlying tied object.

Thanks!
/Autrijus/

[Autrijus Tang]

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/