m4 module loader interface simplifications

[Gary V. Vaughan]

While pondering on slimming down the number of builtins in M4-2.0, it  
occurred to me that load and unload are much lower level than we need  
to expose to the programmer.

I think we should abstract away the difference between {s,}include of  
an m4 file and of a dso, and do away with load/unload altogether.   
It's perfectly possible to keep track of which builtins are still  
attached to m4 macros, and to unload a module again once it no longer  
provides any code that can still be accessed... but, even that I think  
is unnecessary.  After all, why would someone load  a module in the  
first place if they don't want to use the code it provides?

The nice thing about that is that the cli also gets simpler, since  
instead of having to pass --module-directory, M4 would use the same  
search path for dso's as for m4 files, and adjust it with -I and -B  
parameters.  There would be no need for --{,un}load-module at all,  
since dso's would be listed on the command line just like m4 files.

This in turn opens the possibility of mixed dso/m4 modules.  Such a  
module would be a directory named after the module containing m4  
files, one of which should have a predictable name (__init__.m4{,f} a  
la python?  or an m4 file with the same name as the containing  
directory?) that
runs when the module is loaded, and can pull in code from other files  
in that module.

Any thoughts?

Cheers,
        Gary
--
  ())_.              Email me: address@hidden
  ( '/           Read my blog: http://blog.azazil.net
  / )=         ...and my book: http://sources.redhat.com/autobook
`(_~)_

PGP.sig
Description: This is a digitally signed message part