* 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 _______________________________________________ m4-discuss mailing list [email protected] http://lists.gnu.org/mailman/listinfo/m4-discuss
