Re: Would timevar be accepted in gnulib?

[Bruno Haible]

Hi Akim,

> > What do you think? Do you think the list-of-lists use-case makes sense?
> > Do you think configuring the list at run time is something people may want
> > to do?
> 
> You have a strong point here.  But I don’t know if there would
> be actual users for such dynamic timers.

OK, no dynamically allocated timevars then.

But what about the list-of-lists use-case? I think it's pretty natural that,
when a computation consists of several phases, each (or at least some) of
the phases consists of several sub-phases.


> I guess I should have said
> ’set’ instead of ‘list’, the order does not matter, except for
> the order used to display the result.

Since the order matters for printing, it's a 'list', not a 'set'.

> > Approaches (b), (c), (d) have the advantage that the abstraction is easier
> > to understand, because it follows common C idioms (define structs and 
> > reference
> > them through pointers instead of IDs).
> 
> I disagree here.  You seem to claim that an abstraction is easier
> to understand when you understand the implementation, which kind
> of defeats the point of the abstraction.

I like abstractions too. But I also see that many people have problems
grokking abstractions when they don't see the implementation or when the
abstractions are not well explained.

> > (d) has the further big advantage that the list can be configured at run 
> > time.
> > For example, if a compiler has dynamically loadable passes (like GNU ld),
> 
> Really?  ld is dlopening some of its passes?

Yes. I meant the link-time optimization. See '-fuse-linker-plugin' in
https://gcc.gnu.org/onlinedocs/gcc-8.2.0/gcc/Optimize-Options.html

Bruno