On Thu, Sep 04, 2008 at 09:48:09AM -0700, chromatic via RT wrote:
> > I don't think we need any specialized opcodes for this -- simply
> > being able to introspect and dynamically modify the current
> > interpreter's HLL mapping tables ought to be sufficient.
> >
> > (Introspection of HLL mappings is likely to end up being important
> > for the compiler toolkit related libraries anyway, so that a toolkit
> > can generate correct mapping code in the places where Parrot doesn't
> > already handle it.)
>
> How would the interface look? Are methods on the
> Interpreter PMC appropriate, or do you have something else in mind?
I don't have a specific interface in mind. Methods on an
Interpreter PMC would be just fine, and are probably preferable:
## Map Parrot C<String> to Perl 6 C<Str>
.local pmc core_type, hll_type, interp
core_type = get_class 'String'
hll_type = get_class 'Str'
interp = getinterp
interp.'hll_map'(core_type, hll_type)
But it could also be potentially be done with a hash-like interface
of some sort similar to how we do other interpreter-introspection
types of things:
.local pmc interp, hllmap
interp = getinterp
hllmap = inter['hllmap']
## use a hash-like interface on hllmap to query/set mappings
hllmap['String'] = 'Str'
I suspect that the hash-like interface is less likely now that
we have eliminated integer type ids from the PIR-level
programming interface -- which probably argues for a method-based
approach instead.
Pm
