Well, it was a long shot. Nothing is ever as easy as it seems! The problem with this ticket is that we need all sorts of different information, none of which is available at the same time. We need to know the syntax that's used by the op (using '=' or not) which is known in the parser but not elsewhere. We need to know the types of parameters, so that we can know the long name of the opcode, so we can know whether the first argument is OUT or not.
The next best solution I can think of is to attach a flag to the instruction node in the parse tree that "used_assign_syntax" or something. Then the bytecode generator can check that flag to make sure the syntax matches the given opcode. This is bad for a number of reasons, but there don't seem to be many other ways to get all the information we need in one place. --Andrew Whitworth On Wed, Feb 11, 2009 at 7:37 PM, kjstol <parrotc...@gmail.com> wrote: > 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. >> >
