develooper Front page | perl.perl5.porters | Postings from November 2022

Re: Other op types with _AUX structures

Thread Previous | Thread Next
Dave Mitchell
November 7, 2022 13:32
Re: Other op types with _AUX structures
Message ID:
On Mon, Oct 31, 2022 at 06:31:42PM +0000, Paul "LeoNerd" Evans wrote:
> > I wonder if it might make more sense to make the `op_aux` member just
> > a part of the BASEOP structure so that *any* op can make use of it.
> > This would make UNOP_AUX redundant, so presumably we'd then make it a
> > synonym of UNOP itself.

But then that costs an extra pointer of storage for every op, when only a
few ops need the aux field.

It was always my intention when I added UNOP_AUX, that if anything more
than op_first was needed, then it could be handled by the child pointed to
by the op_first, which could be LOGOP or LISTOP etc

So if you think need a LISTOP_AUX, you just create a UNOP_AUX with a
LISTOP as its only child.

Or for the multiple children case, you can just cheat a bit and have a
UNOP with multiple children: BINOP and LISTOP are just optimisations of a
UNOP which have a second pointer to allow you to access the second/last
element more conveniently. If you don't need that quick access, then a
UNOP is fine. This is in fact what multiconcat does.

>   * I don't know why UNOP_AUX_item exists as its own thing. It's a
>     union of a few types (PADOFFSET, SV *, IV, UV, char * or SSize_t)
>     so as to be a bit more generically useful. But, we already have a
>     far more useful union type that can store just about any type. It's
>     called "ANY".

Probably just using ANY would have been a better approach. I can't
remember why I didn't use it back then.

>   * Most uses of these "ANY" vectors are likely to have only a very
>     small number of elements in

Well in their original uses, it was expected that there would be several
elements. For example, $x[1][2] uses 4. Maybe your envisioned uses would
have fewer??

> - maybe just one or two. In these cases
>     it'd probably be wasteful to Newx() an entire ANY vector of just
>     one or two items. I'm therefore thinking that there should be some
>     functions to generate ANY-augmented OPs which take the size of
>     the ANY vector required, and if that's "a small number"[1] it would
>     just roll that ANY vector into the alloc'ed OP node itself;
>     otherwise it could Newx() it separately.

That sounds like a lot of extra complexity? Are you thinking that some
new op types would have a fixed number of fields and so would just access
them directly in the fields of the OP, while other op types would have a
variable number, which if less than N (for some small N) would do a
BODILESS_IV style hack and have op_aux point back to into the op itself,
while for longer, op_aux would point to a malloced buffer??

Given the relatively uncommon frequency of op_aux ops, it seems like a lot
of extra complexity for relatively little memory savings.

Overhead, without any fuss, the stars were going out.
    -- Arthur C Clarke

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