Simon Cozens wrote:
>
> On Sun, Dec 02, 2001 at 02:21:38AM -0500, Jeff G wrote:
> > Currently vtable.h is dynamically constructed from what would appear
> > to be a union of all possible operators on {int,num,string}. Now, this
> > is certainly handy (especially after having to cast one type to another,
> > and making heavy use of said vtable entries), but this will also become
> > unwieldy quickly. One simple example we have right now is the existence
> > of operations like PerlNum_logical_or.
>
> I don't think there'll be any more we want to add.
Are you quite sure? Implementing things like arrays of PMCs will be hard
without operations like set_value(PMC* pmc, INTVAL index). And don't get
me started about things like native Scheme list types... Cons, car, and
cdr operations would probably add at least nine entries at a minimum. Or
are PMCs that are formed of compound scalars going to be implemented in
some other new fashion, or entirely at the assembly level?
> > It's nice to have the ability to call any vtable method blithely
> > against any PMC, and in fact the current PMC strings &c do just that.
> > (Incidentally it would be nice to have some way to identify a value by
> > other than an if(){}else(){} on its vtable member...)
>
> I don't see what you mean - isn't this what pmc->vtable->type is about?
I suppose so, but it still feels rather crufty to me for some reason.
Maybe a simple pmc->get_type() function would do the trick?
> > Looking at the current tests, apparently the new 'interpreter' PMC
> > also uses type 0, so the problem would appear to be slightly deeper than
> > what I've commented on.
>
> That's just a hack. I think you're expecetd to know that interpreter PMCs
> aren't real ones. However, type 0 will soon be used by a PerlUndef class.
Yes, I figured that the interpreter PMC type was more or less a
placeholder. I simply was pointing out that more than one type was
currently residing on the same index.
> > Incidentally, I personally would find something
> > like 'new P0,"interpreter"' or 'new P0,"perl_scalar"' clearer than a
> > cryptic digit.
>
> Yep. This requires fixing the assembler to know about the enum in vtable.h
That enum won't mean much once we have PMCs in there gamboling about,
changing vtables dynamically between int and string and such... Maybe we
should add a small layer of indirection and end up with class names such
as 'perl_undef' and 'perl_scalar' that will isolate the code below the
layer where the compiler author will have to care about what initial
type the PMC is beyond undef/scalar/array/hash?
> Simon
>
> --
> The use of COBOL cripples the mind; its teaching should, therefore, be
> regarded as a criminal offence.
> -- Edsger W. Dijkstra, SIGPLAN Notices, Volume 17, Number 5
