pmc syntax
Klaas-Jan Stol
Is there any documentation about the complete syntax for pmc files when
writing PMCs (this time in C)? I found genclass.pl and pmc2c.pl, but I
couldn't find anything about all keywords that can be used. In
particular, I wrote down some scenarios. Maybe there are some more cases
than these.
Case 1:
pmclass Foo {
[ vtable methods here]
}
This one is simple. It just creates a new PMC class, as a superclass. If
I understand correctly, when writing such a class, you would start with
genclass.pl. Or, would extending "default" be ok as well?
Case 2:
pmclass Foo extends Bar {
[vtable methods here]
}
A PMC class extending from Bar. Extra vtable methods for Bar's extra
functionality (WRT Foo), or vtable methods with different behaviour than
Bar, must be written.
Case 3:
pmclass Foo does Bar {
[vtable methods here]
}
I don't really understand what this does. I understand the "does"
keyword says something about an interface ("Bar") that is implemented by
this class ("Foo"). Why would you do this? Why does one need this? I saw
in pmc2cl.pl that there are a number of interfaces defined already. Is
there anything written about these interfaces?
Thanks,
klaas-jan
Will Coleda
On Jul 27, 2005, at 4:00 PM, Klaas-Jan Stol wrote:
> hi,
>
> Is there any documentation about the complete syntax for pmc files
> when writing PMCs (this time in C)?
I think that's technically the only way to write PMCs. (things
written in PIR are Objects). And, as you've seen, pmc2c.pl is
currently where most of this documentation lives.
> I found genclass.pl and pmc2c.pl, but I couldn't find anything
> about all keywords that can be used. In particular, I wrote down
> some scenarios. Maybe there are some more cases than these.
>
> Case 1:
>
> pmclass Foo {
>
> [ vtable methods here]
>
> }
>
> This one is simple. It just creates a new PMC class, as a
> superclass. If I understand correctly, when writing such a class,
> you would start with genclass.pl. Or, would extending "default" be
> ok as well?
>
A note: genclass gives you a PMC with a *lot* of empty methods. You
should delete all the ones that you don't actually want to override.
You don't need to extend default, that's the default if you don't
override something.
Also note that you can put in methods that don't correspond to vtables.
> Case 2:
>
> pmclass Foo extends Bar {
>
> [vtable methods here]
>
> }
>
> A PMC class extending from Bar. Extra vtable methods for Bar's
> extra functionality (WRT Foo), or vtable methods with different
> behaviour than Bar, must be written.
>
Yup. Note that you can specify multiple extendees.
> Case 3:
>
> pmclass Foo does Bar {
>
> [vtable methods here]
>
> }
>
> I don't really understand what this does. I understand the "does"
> keyword says something about an interface ("Bar") that is
> implemented by this class ("Foo"). Why would you do this? Why does
> one need this? I saw in pmc2cl.pl that there are a number of
> interfaces defined already. Is there anything written about these
> interfaces?
Does corresponds to the C<does> opcode: there's no formal definition
of these interfaces, so there's no concrete list: it's only a
convention at this point. pmc2c.pl has a fairly recent list of what's
in play, and I've updated the POD to reflect these comments below
(some of which are WAGs).
array : container PMC with numerically-keyed elements
event : PMC that can be used with event queue
hash : container PMC with string-keyed elements
library : PMC that corresponds to a dynamic library
ref : PMC that references another PMC
scalar : (only used by the sample dynclasses/foo.pmc)
I'm guessing scalar might correspond directly to things Integer,
String, PerlNum, but no one is using that at the moment.
So, to sum up: when you use does in your PMC, you're not actually
contractually obligated to say that the PMC is going to act a certain
way; so, when I use does in my PASM, I'm not guaranteed anything
other than that you put that keyword in your PMC def.
Regards.
Klaas-Jan Stol
Will Coleda wrote:
>
> On Jul 27, 2005, at 4:00 PM, Klaas-Jan Stol wrote:
>
>> hi,
>>
>> Is there any documentation about the complete syntax for pmc files
>> when writing PMCs (this time in C)?
>
>
>
> I think that's technically the only way to write PMCs. (things
> written in PIR are Objects). And, as you've seen, pmc2c.pl is
> currently where most of this documentation lives.
yep, thanks. In a previous posting (or blog entry? I can't find it at
this moment), I think Dan mentioned that "the plan" was to be able to
write PMCs either in PIR or in C. Depending on the server running
Parrot, one of both implementations would be used; sometimes it may not
be possible to have you own custom PMCs installed, so you would have to
use the PIR version.
But you're right, creating PMCs in PIR uses the newclass/subclass
syntax, which makes them objects. But, if I understood correctly, they
behave more or less the same, right? (in that case, effectively it
wouldn't make any difference)
>
>> I found genclass.pl and pmc2c.pl, but I couldn't find anything about
>> all keywords that can be used. In particular, I wrote down some
>> scenarios. Maybe there are some more cases than these.
>>
>> Case 1:
>>
>> pmclass Foo {
>>
>> [ vtable methods here]
>>
>> }
>>
>> This one is simple. It just creates a new PMC class, as a
>> superclass. If I understand correctly, when writing such a class,
>> you would start with genclass.pl. Or, would extending "default" be
>> ok as well?
>>
>
> A note: genclass gives you a PMC with a *lot* of empty methods. You
> should delete all the ones that you don't actually want to override.
>
> You don't need to extend default, that's the default if you don't
> override something.
You mean, this is done implicitly, right? (in Java terms: writing a
"class Foo { ... }" would mean Foo is extending "Object")
>
> Also note that you can put in methods that don't correspond to vtables.
These would be called as... ehm... "methods" :-), right?
>
>> Case 2:
>>
>> pmclass Foo extends Bar {
>>
>> [vtable methods here]
>>
>> }
>>
>> A PMC class extending from Bar. Extra vtable methods for Bar's extra
>> functionality (WRT Foo), or vtable methods with different behaviour
>> than Bar, must be written.
>>
>
> Yup. Note that you can specify multiple extendees.
I don't know very much about multiple inheritance, but I do know a bit
of C++ (not very fluently); what if you would inherit from 2 classes
that both offer the same method?
Which one is called? (I think C++ just won't compile, but it's been some
time I used it)
This will change later, right? Otherwise your PMC could be lying, saying
it *does* something, which it doesn't.
>
> Regards.
>
I came across another thing WRT PMC writing singleton.
Suppose I would want to have my own custom representation of "None". I
created a class extending None, but this child class is no singleton
anymore (I created 2 instances, compared them: they proved to be 2
different objects). Looking in none.pmc:
INTVAL is_equal(PMC* other) {
MMD_None: {
return 1;
}
MMD_DEFAULT: {
return 0;
}
}
}
What should I do to have my child class be a singleton too? (just
extending singleton as well?)
thanks for your help,
klaas-jan
Leopold Toetsch
> Suppose I would want to have my own custom representation of "None".
> What should I do to have my child class be a singleton too? (just
> extending singleton as well?)
None isn't a singleton. But have a look at the Null PMC or better env.pmc.
$ grep singletion classes/*.pmc
(the way to create singletons might change though)
> thanks for your help,
> klaas-jan
leo
Klaas-Jan Stol
> Klaas-Jan Stol wrote:
>
>> Suppose I would want to have my own custom representation of "None".
>
>
>> What should I do to have my child class be a singleton too? (just
>> extending singleton as well?)
>
>
> None isn't a singleton. But have a look at the Null PMC or better
> env.pmc.
>
> $ grep singletion classes/*.pmc
>
mmm, I looked at classes/none.pmc, this is a copy/paste:
===============
#include <assert.h>
static PMC * Py_None;
pmclass None singleton {
===============
Maybe this is wrong?
I'll have a look at the null pmc, thanks!
> (the way to create singletons might change though)
>
>> thanks for your help,
>> klaas-jan
>
>
> leo
klaas-jan
Leopold Toetsch
> mmm, I looked at classes/none.pmc, this is a copy/paste:
> ===============
> #include <assert.h>
>
> static PMC * Py_None;
>
> pmclass None singleton {
Ah, yep - None is a singleton too - sorry for my confusion.
So it should be rather easy to subclass None, implement get/set_pointer
and use a distinct file-static PMC* storage for your singleton.
leo
Klaas-Jan Stol
ah great. it works! :-). Apparently, inheriting from a singleton class
doesn't make the child class a singleton, you have to add the
"singleton" keyword in the class definition header.
one more question though:
1a: when are set_pointer and get_pointer actually called?
1b: in set_pointer (I copied it from None.pmc) an assertion is done. Why
is this? (this is also part of question 1a: set_pointer is called once,
apparently?)
void set_pointer(void* ptr) {
assert(!Lua_Nil);
Lua_Nil = (PMC*) ptr;
}
Anyway:
P0 = new "LuaNil"
print P0
prints "nil". Great! :-)
thanks.
klaas-jan
Leopold Toetsch
> 1a: when are set_pointer and get_pointer actually called?
From pmc.c:pmc_new
> 1b: in set_pointer (I copied it from None.pmc) an assertion is done. Why
> is this? (this is also part of question 1a: set_pointer is called once,
> apparently?)
Well, it asserts that you really just create one PMC of that kind.
> thanks.
> klaas-jan
leo