Questions about abstract pmcs
Stéphane Payrard
because one needs them as base pmcs so as to declare
pseudo-registers. This is a prerequisite to add pmc type checking
to imcc. Working on a patch to fix that, I got some questions to
be answered.
Unlike other pmcs, abstract pmcs have names that are all lower
case, is that deliberate?
What is the difference between declaring a pmc as C<noinit> or as
C<abstract>? Currently when one is set, the other is also set.
For sake of some kind of introspection,
it may useful to generate a vtable in the C file generated for an
abstract class albeit with init methods that trigger exception.
--
stef
Leopold Toetsch
> Abstract pmcs should appear in core_pmcs.h and pmctypes.pasm
> because one needs them as base pmcs so as to declare
> pseudo-registers. This is a prerequisite to add pmc type checking
> to imcc.
I don't think that we need the type names of abstract PMCs.
> Unlike other pmcs, abstract pmcs have names that are all lower
> case, is that deliberate?
Yes.
> What is the difference between declaring a pmc as C<noinit> or as
> C<abstract>? Currently when one is set, the other is also set.
C<abstract> is unimplemented.
> For sake of some kind of introspection,
> it may useful to generate a vtable in the C file generated for an
> abstract class albeit with init methods that trigger exception.
The C<isa> of derived type shows abstract base types too. That's
probably enough. For now, I'd rather not have vtables for these (each
unused piece of memory is kind of an overhead).
But it could be, that we finally have real C<abstract> base types, that
implement some useful functionality on behalf of derived child classes.
> stef
leo
Stéphane Payrard
> Stéphane Payrard <st...@payrard.net> wrote:
> > Abstract pmcs should appear in core_pmcs.h and pmctypes.pasm
> > because one needs them as base pmcs so as to declare
> > pseudo-registers. This is a prerequisite to add pmc type checking
> > to imcc.
>
> I don't think that we need the type names of abstract PMCs.
If one wants to add typechecking to imcc, it is necessary to have
abstract/noinit types.
Example:
.sym scalar var
new var, .Perlint # the instance is a substype of C<scalar>
>
> > Unlike other pmcs, abstract pmcs have names that are all lower
> > case, is that deliberate?
>
> Yes.
>
> > What is the difference between declaring a pmc as C<noinit> or as
> > C<abstract>? Currently when one is set, the other is also set.
>
> C<abstract> is unimplemented.
>
> > For sake of some kind of introspection,
> > it may useful to generate a vtable in the C file generated for an
> > abstract class albeit with init methods that trigger exception.
>
> The C<isa> of derived type shows abstract base types too. That's
> probably enough. For now, I'd rather not have vtables for these (each
> unused piece of memory is kind of an overhead).
There is not so many abstract pmc types and one could manage to
use shorter vtables for these types with init methods that trigger
exceptions. Other methods entries are not necessary (except for some
introspection purpose) because they will never be called.
> But it could be, that we finally have real C<abstract> base types, that
> implement some useful functionality on behalf of derived child
> classes.
My understanding is that we already have that. C<noinit> types
define methods used by derived types. So I still fail to
understand the difference between C<noinit> and C<abstract>
> leo
--
stef
Leopold Toetsch
> Example:
> .sym scalar var
> new var, .Perlint # the instance is a substype of C<scalar>
.sym pmc var
is as good. There isn't any difference. Its even simpler for compiler
writers.
> My understanding is that we already have that. C<noinit> types
> define methods used by derived types. So I still fail to
> understand the difference between C<noinit> and C<abstract>
AFAIK: C<abstract> would be the thing with a vtable which is never
instantiated. It could be useful for overriding a bunch of dynamic
vtable methods on behalf of derived types. We don't have that currently.
> stef
leo
Dan Sugalski
>Stéphane Payrard <st...@payrard.net> wrote:
>> Example:
>
>> .sym scalar var
>> new var, .Perlint # the instance is a substype of C<scalar>
>
> .sym pmc var
>
>is as good. There isn't any difference. Its even simpler for compiler
>writers.
Which brings up a question. What's the difference between .local and .sym?
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Harry Jackson
> Which brings up a question. What's the difference between .local and .sym?
I was hoping someone would ask this.
Harry
Stéphane Payrard
> At 7:30 PM +0100 1/12/04, Leopold Toetsch wrote:
> >Stéphane Payrard <st...@payrard.net> wrote:
> >> Example:
> >
> >> .sym scalar var
> >> new var, .Perlint # the instance is a substype of C<scalar>
> >
> > .sym pmc var
> >
> >is as good. There isn't any difference. Its even simpler for compiler
> >writers.
>
> Which brings up a question. What's the difference between .local and .sym?
> --
Currently, there is none. So I went for the shortest:
grep -n -e LOCAL imcc.l
imcc.l:181:".sym" return(LOCAL);
imcc.l:206:".local" return(LOCAL);
--
stef
> Dan
Leopold Toetsch
> Which brings up a question. What's the difference between .local and .sym?
They are equivalent for plain code. *But* C<.local> was already used for
local labels inside macros of assembler.pl - so is it now - and it was
used for declaring variables in imcc.
$ perldoc imcc/docs/macros.pod
That means C<.sym> is the only way to declare a variable inside a macro.
When we have the external macro preprocessor, we can easily get rid of
that ambuigity.
leo
Melvin Smith
Its a relic. I had planned to make .sym usable at varying scope levels (as
opposed to .local). I've now come to the conclusion that .sym is not very
descriptive and I will probably use .global and other more specific
names rather than changing .sym
In any case, its there now and will probably stay for imcc hackers who
prefer variety. :)
-Melvin