On Fri, 2025-06-13 at 09:34 -0700, Andrii Nakryiko wrote:
> On Wed, Jun 11, 2025 at 5:21 AM Eduard Zingerman <eddyz87@xxxxxxxxx> wrote:
> >
> > What do you think about a more recursive representation for presets?
> > E.g. as follows:
> >
> > struct rvalue {
> > long long i; /* use find_enum_value() at parse time to avoid union */
> > };
> >
> > struct lvalue {
> > enum { VAR, FIELD, ARRAY } type;
> > union {
> > struct {
> > char *name;
> > } var;
> > struct {
> > struct lvalue *base;
> > char *name;
> > } field;
> > struct {
> > struct lvalue *base;
> > struct rvalue index;
> > } array;
> > };
> > };
> >
> > struct preset {
> > struct lvalue *lv;
> > struct rvalue rv;
> > };
> >
> > It can handle matrices ("a[2][3]") and offset/type computation would
> > be a simple recursive function.
> >
>
> Why do we need recursion, though? All we should need is an array specs
> of one of the following types:
>
> a) field access by name
> a.1) we might want to distinguish array field vs non-array field
> to better catch unintended user errors
> b) indexing by immediate integer
> c) indexing by symbolic enum name (or we can combine b and c,
> whatever works better).
>
> And that's all. And it will support multi-dimensional arrays.
>
> We then process this array one at a time. Each *step* itself might be
> recursive: finding a field by name in C struct is necessarily
> recursive due to anonymous embedded struct/union fields. But other
> than that, it's a simple sequential operation.
>
> So unless I'm missing something, let's not add data recursion if it's
> not needed.
Recursive representation I simpler in a sense that you need only one
data type. W/o recursion you need to distinguish between container
data type that links to each constituent.
Plus in a computation function you need to distinguish first step from
all others. Recursive organization simplifies both data types and
computation function.
