I almost couldn't believe how I could have missed that, until I remembered what was the problem.Thing is, there are some ops (and of course, this should be possible, as users can load dynops) that have different variants, with different directions for the first arg. For instance: (can't remember the real example; just try run make test with the patch)
$P0 = foo "x" # foo_p_sc, variant 1 $P0 = foo # foo_p, variant 2 If you know the short name of an op, you get a semi-random variant of that op (that is, the byte code). So, you can't know which opinfo you get (for what variant). You can ONLY know the right variant, if you know the full signature of the op, something that you don't know until bytecode generation (happens way later in imcc). I'm probably not explaining this correctly or very clearly, but I can guarantee it will never work. (unless, of course, you precalculate the full signature right there, but... let's just stick with "good luck" as the appropriate message for that :-) I've tried this approach, it doesn't work, unfortunately. Also, I would strongly suggest that we disallow use of full-signatured opnames in PIR. It's not needed, as literally nobody uses ops like "print_sc". Also, it might be slightly more efficient, as whenever an is_op() call is done with a non-op, there's 2 searches, 1 for the short name, 1 for the long name. (and I think PIRC can't even handle it as it stands now, although implementability shouldn't be a valid reason, I admit that. I wonder whether IMCC will handle it fully correctly in all cases) kjs On Wed, Feb 11, 2009 at 8:54 PM, Andrew Whitworth via RT < parrotbug-follo...@parrotcode.org> wrote: > I've attached my first attempt to make this work. I had hoped we could > combine the is_op check in imcc.l with this check in imcc.y to prevent > having to dig into the oplib twice for each op, but that's an > optimization to consider at a later date. > > The patch checks the op to ensure that it's first argument is an "OUT" > argument. If it is not, we throw a syntax error exception. > > I haven't tested this yet, no flex/bison on this computer. I'll do it at > home tonight. If anybody else can test this, or has an opinion on it, or > whatever let me know. >
