analogy pmc/content with inode/file
Stéphane Payrard
Unix inodes/files which I use as a mnemonic.
PMCs are the equivalent of inodes, each one
reference some content which is the equivalent of a file.
C<set_pmc>, when the source and the destination pmcs are of the same type,
is like creating a hard_link to a file. The two pmcs share the
same content.
C<set_pmc>, when the destination pmc is a reference, is like
creating a symbolic link with the difference that there cannot
dangling reference pmc thanks to reference counting.
C<assign_pmc> is like copying a file to another. After the
assignement the two pmcs and their contents are independant.
Does the analogy holds? or am I mistaken?
I certainly don't pretend that one can carry further the analogy.
--
stef
Leopold Toetsch
> I want to make an loose analogy between pmc/their_content and
> Unix inodes/files which I use as a mnemonic.
> PMCs are the equivalent of inodes, each one
> reference some content which is the equivalent of a file.
> C<set_pmc>, when the source and the destination pmcs are of the same type,
> is like creating a hard_link to a file. The two pmcs share the
> same content.
,--[ pdd02_vtables.pod ]------------------------------------------
| void set_pmc(INTERP, PMC* self, PMC* value)
| Sets the value of the PMC in self to the value of the
| PMC in value.
|
| void assign_pmc(INTERP, PMC* self, PMC* value)
| Sets the value of the PMC in self to the value of the
| PMC in value by copying the value.
`-----------------------------------------------------------------
So probably yes. OTOH having e.g. two array PMCs pointing to the same
array structure could be rather error prone.
I think, we have to consider first variables vs values. Variables have a
name and hold values (the PMCs). It depends on the HLL, what e.g. an
assignment is doing:
i = j # Python - both variables refer to the same value
i += k # mutable objects are changed in place
# immutable objects are rebound to hold the new value
@a = @b # Perl - copy array
So normally setting a value happens one level higher. But in leaf
functions and in the absence of introspection, I can imagine that the
optimizer converts lexical opcodes to PMC-only operations, depending on
the semantics of the HLL.
leo
Dan Sugalski
>Stéphane Payrard <st...@payrard.net> wrote:
>> I want to make an loose analogy between pmc/their_content and
>> Unix inodes/files which I use as a mnemonic.
>
>> PMCs are the equivalent of inodes, each one
>> reference some content which is the equivalent of a file.
>
>> C<set_pmc>, when the source and the destination pmcs are of the same type,
>> is like creating a hard_link to a file. The two pmcs share the
>> same content.
>
>,--[ pdd02_vtables.pod ]------------------------------------------
>| void set_pmc(INTERP, PMC* self, PMC* value)
>| Sets the value of the PMC in self to the value of the
>| PMC in value.
>|
>| void assign_pmc(INTERP, PMC* self, PMC* value)
>| Sets the value of the PMC in self to the value of the
>| PMC in value by copying the value.
>`-----------------------------------------------------------------
>
>So probably yes. OTOH having e.g. two array PMCs pointing to the same
>array structure could be rather error prone.
>
>I think, we have to consider first variables vs values. Variables have a
>name and hold values (the PMCs).
Not quite. The PMC is the variable, not the
value. The contents of the PMC are the value.
>It depends on the HLL, what e.g. an
>assignment is doing:
These aren't all assignment, and the chosen punctuation is really unfortunate.
> i = j # Python - both variables refer to the same value
This isn't assignment. This is name rebinding --
that is, two names in some namespace refer to the
same PMC
> i += k # mutable objects are changed in place
> # immutable objects are rebound to hold the new value
This is one of those bizarre mutant cases -- it's really a method call.
> @a = @b # Perl - copy array
This is assignment, sort of. If you squint hard,
given the stuff perl's doing behind the scenes.
In all these it's important to note that in most
languages (certainly the ones we care about)
objects are *reference* types, not value types.
That is, there's a level of indirection (likely
an ObjectReference or just generic PMCReference
PMC) between the name and the ultimate object
structure, something we don't do right now.
--
Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk