Front page | perl.perl5.porters |
Postings from December 2021
On Sun, Dec 05, 2021 at 10:45:58AM +0000, Paul "LeoNerd" Evans wrote: > On Sat, 4 Dec 2021 14:16:37 +0000 > "Paul \"LeoNerd\" Evans" <leonerd@leonerd.org.uk> wrote: > > > My plan is to create two new .c files to contain subsections of what > > is currently in op.c: > > > > peep.c: to contain the finalizer and peephole optimiser > > I now have an (as-yet unpushed) branch which does this part; it doesn't > seem too bad. I had to make a few static functions into internal API, > but that didn't seem too bad. > > Sizes now: > > > ck.c: to contain the opchecker functions (Perl_ck_*) > > This part seems like it might go roughly the same way, requiring some > more currently-static functions to be exposed. But here I find more of > a question: it's intended that custom operators can provide their own > opchecker functions. Several of the currently-static functions used by > existing opcheckers feel like they would be useful to custom checkers > too. Perhaps for at least some of these, a case might be made to make > them exposed API so that custom ops can use them too? Few to none of these were written with any intent of being a coherent, public, supportable API. So as-is there's risk in exposing and ossifying interfaces that constrain implementation details and prevent refactoring or optimisation. (That's not "no" - that's "tread carefully") Also, more pragmatically, it's foolish to "declare" them API unless what they do can be documented, and what they guarantee can be tested. Else we're just setting ourselves up for more pain in the future. For example, fold_constants *must* be called with PL_curcop == &PL_compiling That sort of pre-condition belongs in documentation, and I don't know what other traps lurk in these various functions. Quite often the names are deceptive - for example, I don't know if fold_constants actually does *mandatory* fixups - ie despite having a name that shouts "I'm an optimisation step" it's actually essential. > If (some of) these became public API that would help move the > opcheckers to their own file, as well as allowing custom code in CPAN > modules to make use of them as well. I don't see why it's necessary for *any* of these to be a public API to move the opcheckers to a different file - we have plenty of non-static functions that are not public (and not exported on platforms with decent linker hygiene). I don't see any risk in marking anything 'p' rather than 's' in embed.fnc - ie turning functions non-static. That's not making any promises that might be hard to keep, or we might regret with hindsight. We can think about what APIs *should* be independent of that change, without rushing it. Otherwise we're just assuming that our 25-year old internal spaghetti makes sense as exposed APIs, which I very much doubt. Nicholas ClarkThread Previous | Thread Next