Re: Questions about abstract pmcs
Stéphane Payrard <[EMAIL PROTECTED]> 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. > 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 or as > C? Currently when one is set, the other is also set. C 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 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 base types, that implement some useful functionality on behalf of derived child classes. > stef leo
Re: Questions about abstract pmcs
On Mon, Jan 12, 2004 at 10:05:51AM +0100, Leopold Toetsch wrote: > Stéphane Payrard <[EMAIL PROTECTED]> 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 > > > 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 or as > > C? Currently when one is set, the other is also set. > > C 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 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 base types, that > implement some useful functionality on behalf of derived child > classes. My understanding is that we already have that. C types define methods used by derived types. So I still fail to understand the difference between C and C > leo -- stef
Re: Questions about abstract pmcs
Stéphane Payrard <[EMAIL PROTECTED]> wrote: > Example: >.sym scalar var >new var, .Perlint # the instance is a substype of C .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 types > define methods used by derived types. So I still fail to > understand the difference between C and C AFAIK: C 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
Re: Questions about abstract pmcs
At 7:30 PM +0100 1/12/04, Leopold Toetsch wrote: Stéphane Payrard <[EMAIL PROTECTED]> wrote: Example: .sym scalar var new var, .Perlint # the instance is a substype of C .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 [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Questions about abstract pmcs
Dan Sugalski wrote: Which brings up a question. What's the difference between .local and .sym? I was hoping someone would ask this. Harry
Re: Questions about abstract pmcs
On Mon, Jan 12, 2004 at 03:16:50PM -0500, Dan Sugalski wrote: > At 7:30 PM +0100 1/12/04, Leopold Toetsch wrote: > >Stéphane Payrard <[EMAIL PROTECTED]> wrote: > >> Example: > > > >>.sym scalar var > >>new var, .Perlint # the instance is a substype of C > > > > .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
Re: Questions about abstract pmcs
Dan Sugalski <[EMAIL PROTECTED]> wrote: > 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
Re: Questions about abstract pmcs
At 09:55 PM 1/12/2004 +0100, Stéphane Payrard wrote: On Mon, Jan 12, 2004 at 03:16:50PM -0500, Dan Sugalski wrote: > 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); 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