On Thu Dec 13 05:54:17 2007, kjs wrote: > On Tue Jun 14 02:30:00 2005, chip wrote: > > It makes sense to allow e.g. C<$P0 = add $P1, $P2> as alternative > > syntax for C<add $P0, $P1, $P2>. However, when the first parameter is > > "inout" rather than "out", assignment syntax is *not* appropriate. > > > > For example, C<substr $P0, 1, 2, "x"> actually modifies $P0 rather > > than just assigning to it, so C<$P0 = substr 1, 2, "x"> is just wrong, > > and should be a compile-time error. > > In order to make this work, a check should be done for each op in the > pir compiler. Besides the question whether an identifier is an op > (is_op() ), its meta-data must be retrieved. While I'm sure this is > possible, by having the .ops pre-processor store the mode of the op > parameters somewhere, it does involve extra checks, making the pir > compiler slower. > > Also, for ops in dyn.op.libs written by third parties, which are only > distributed in binary form (as the .so or .dll file), which does not > include any source, this check cannot be done, EXCEPT this check is ALSO > done during runtime. > > In short, this issue is a pain to solve; is it worth fixing? > (probably that's why this ticket is stalled.)
on second thought, I had another idea. currently the PIR compiler (IMCC) will select the appropriate operation based on the types of the arguments. So: print "hi" will become: print_sc "hi" # print s(tring) c(onstant). Currently, you can also write: $S0 = "hi" $S0 = print Maybe it's an idea that inout arguments are marked using the same strategy; so for instance: $S0 = print will be translated to: print_sco # "print" s(tring) c(onstant) o(utput) or whatever letter/mark is chosen to mark that a parameter is an output parameter; surely, Parrot won't have a print_sco instruction, only a print_sc (or, if you want to make it explicit: print_sci). This way, there's no additional overhead of checking any meta data, but we can easily emit an error message when writing stuff like "$S0 = print". just some thoughts. kjs
