Re: m4sugar and m4 1.6, bison

* Eric Blake wrote on Sun, Jul 13, 2008 at 03:18:37PM CEST:
> According to Ralf Wildenhues on 7/12/2008 12:39 AM:
> | * Ralf Wildenhues wrote on Sat, Jul 12, 2008 at 08:11:55AM CEST:
> |> # m4_make_macro_name(STRING)
> |> # Turn all characters not fitting to be a macro name into '_'.
> |> m4_define([m4_make_macro_name],
> |> [m4_bpatsubst([$1], [...])dnl
> |> ])
>
> GNU m4 allows any character in a macro name (you just have to use indir
> and defn to access such macros).  I think your approach can be made to
> work without having to introduce m4_make_macro_name, and thus avoid
> collisions altogether.

OK, but this fact (the need to use indir and defn) plus this:

> But there is still the matter of how to remove all
> the stale macros if the key being appended to is redefined as empty.

... are certainly enough of a churn to require that such an improved
algorithm gets a new name, and the old one *remains*, supported with
its current semantics.

> At any rate, I see what you are trying to do - add an additional expense
> of O(n) storage in order to avoid an expense of O(n) time in searching for
> previously supplied entries (m4_append already uses O(n) storage for the
> macro name, so you are just increasing the constant factor).  It seems
> like libtool's ltsugar provides lt_dict* that does something like this
> sort of operation.

Similar, yes.  Maybe it's more useful to introduce something like that
into m4sugar instead of going after m4_append_uniq variations.

> And it certainly seems like something worth pursuing,
> but not until after m4_append is fixed to be O(n) (no scaling improvements
> result by making the search faster if the insertion is still slow).

Agreed.

Cheers,
Ralf