develooper Front page | perl.perl5.porters | Postings from December 2021

Re: Any outstanding branches of op.c? / Split into smaller pieces

Thread Previous | Thread Next
Nicholas Clark
December 5, 2021 11:31
Re: Any outstanding branches of op.c? / Split into smaller pieces
Message ID:
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" <> 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

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 Clark

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