On Nov 28, 9:04 am, [EMAIL PROTECTED] (Joshua Isom) wrote: > How can you know what opcodes a dynamically loaded library provides at > compile time? If there's no other method than interp, then you'll have > to use interp to find out what's valid and what's not, without > redesigning how dynops are handled. >
That's exactly the point. w.r.t. how you can know: you'll have to ask interp. However, how to ask it, if it doesn't allow you to do so? In other words, there's no function to find out. IMCC cheats a bit here; it just pokes into the interpreter guts, but I don't think that's a good solution. kjs > On Nov 27, 2007, at 1:15 PM, [EMAIL PROTECTED] wrote: > > > Hi, > > > Is it possible for parrot embedders to find out whether a certain name > > is an op? > > > IMCC uses a function "is_op", but it's poking in the Parrot_Interp > > structure. The pir compiler must be able to check which names are ops > > and which are not. > > > My goal is to embed a Parrot_Interp in compilers/pirc/new, so that the > > pir compiler is completely separate from the runtime environment. Of > > course, some code must be run after compilation > > (:postcomp, :immediate), but the idea is to keep them separate. > > > I'd like to know whether this approach is desirable (have the pir > > compiler embed a parrot), and whether there are any ideas or proposals > > to fix this. My approach would be to add functions to the embed.h > > interface, as it is some introspection into the parrot runtime. > > > kjs
