Jeff G:
# 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?
Things like that can be implemented as
a) new PMC opcodes, or
b) calls to pmc->vtable->callmethod() (or whatever it'll be called)
# > > 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?
But the PMC doesn't *know* its type. Its type is determined by the
vtable.
# > > 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.
Quick comment: I've been thinking about constructing an 'OpaqueHandle'
PMC type. All the programmer is supposed to know about it is that it
points to Something (usually a C struct, but they don't have to know
that). I'm not sure what trying to access it results in--perhaps it'll
look like a reference from the outside ("ParrotInterp=HANDLE(0xDECAF)"),
or maybe it'll throw a tantrum.
# > > 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?
Why don't we keep both an array and a hash (once they're available) of
types?
--Brent Dax
[EMAIL PROTECTED]
Configure pumpking for Perl 6
"Nothing important happened today."
--George III of England's diary entry for 4-Jul-1776
