develooper Front page | perl.perl5.porters | Postings from August 2023

New API function idea: newLISTOPn()

Thread Next
Paul "LeoNerd" Evans
August 22, 2023 16:15
New API function idea: newLISTOPn()
Message ID:
I quite often find myself writing nontrivially-sized chunks of C code
that construct optree fragments. If the optree contains only base OPs,
UNOPs, BINOPs or LOGOPs then you can usually write the entire tree in a
big nested shape of C code. But not so for LISTOPs, because of the
annoying inconvenience of having to go construct a plain OP_LIST and
then op_convert_list() it to the target type. This results in noisy
code that's hard to read the intent of; e.g.:

  OP *checkop = newLISTOP(OP_LIST, 0, NULL, NULL);
  checkop = op_append_elem(OP_LIST, checkop,
      newSVOP(OP_CONST, 0, SvREFCNT_inc(data->checkobj)));
  checkop = op_append_elem(OP_LIST, checkop,
  checkop = op_append_elem(OP_LIST, checkop,
      newSVOP(OP_CONST, 0, SvREFCNT_inc(data->checkcv)));

  checkop = op_convert_list(OP_ENTERSUB, G_VOID, checkop);

I propose that now we have C99 and we can use __VA_LIST__ in macros, we
could neaten this up enormously into:

  OP *checkop = newLISTOPn(OP_ENTERSUB, G_VOID,
      newSVOP(OP_CONST, 0, SvREFCNT_inc(data->checkobj)),
      newSVOP(OP_CONST, 0, SvREFCNT_inc(data->checkcv)));

This basically requires making a valist-taking function, and wrapping
it in a macro thus:

  #define newLISTOPn(type, flags, ...)  \
      Perl_newLISTOPn(aTHX_ type, flags, __VA_ARGS__, NULL)

Since we already have macros that use __VA_ARGS__, I don't imagine this
will be problematic. I expect that, as well as providing a handy
shortcut for XS modules and the like, there's probably quite a few
places in core code that could be similarly neatened by it.

Before I write up a quick little PR to add this, can anyone spot a
reason why not to?

Paul "LeoNerd" Evans      |  |

Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About