GNU m4

The Road Ahead

General info

What is m4
Features
Uses of m4

Documentation

Manual

Source files

README
TODO
NEWS
ChangeLog
Contributors
Browse it

The Future

Modules
Visions

Feedback

Mailing-lists
Feedback
Discussion Forum

Development

Download
Known bugs

Examples

This site

Sponsor Links

Posters Shop
Movie Posters
Celebrity Photos
Art Prints
College Posters
Tanya Chalkin Kiss
Johnny Depp
Orlando Bloom
Kill Bill: Volume 2
Framed Art Prints

Ideas for future versions of GNU m4

Here are some ideas and suggestion for the future of GNU m4, large and small. The order here is fairly random.

See also the TODO file.


Guile as an extension language

Guile can be used as an extension language so complicated macros can be written in Scheme while still maintaining the m4 interface. It will require some changes to the base code, as guile cannot be used from a module.

There is no-one working on this now. Do you want to volunteer?


UTF-8 or wide characters

GNU m4 should be able to handle UTF-8 input or wide characters so it can be more usable for different environments.

There is no-one working on this now. Do you want to volunteer?


Syntax: persistent quotes

Persistent quotes is a way of getting text unharmed through m4's processing. While normal quotes are stripped when a quoted string is read, the persistent quotes are removed just before being output. This will ensure that the quoted text is always output verbatim.

The bulk of the changes will be in the parser (in input.c function next_token). Persistent quotes cannot be nested, they must balance within a normally quoted string, but normal quotes need not balance within persistent quotes (neither within persistent quotes within normal quotes). The quotes should be removed before being shipped out (in macro.c).

There is no-one working on this now. Do you want to volunteer?


Syntax: removable comments

With the syntax table a category for discardable comments can be defined, causing that type of comments to be discarded.

There is no-one working on this now. Do you want to volunteer?


Option: remove comments

There should be an option (--discard-comments) to get m4 to discard comments instead of passing them to the output.

Done in version 1.4n


Option: show dependencies

There should be an options to generate makefile dependencies for an M4 input file.

It is not enough to scan the files for includes, as file names can be generated and builtins renamed. To make it work, m4 will have to do a complete run of the input file, discard the output and print the dependencies instead.

It cannot be made to work in all cases when input file names are generated on the fly.

There is no-one working on this now. Do you want to volunteer?


Option: render GNU m4 safer

There should be a --safer option that disables all functions, that could compromise system security if used by root. It will have to include various functions, such as file inclusion, sub shells, module loading, ...

There is no-one working on this now. Do you want to volunteer?


Option: import environment

An option to defined each environment variable as a macro on startup would be useful in many cases.

Done in version 1.4n


Builtin: quote expanded text

A builtin to quote expanded text would be useful. Now it is not possible to quote the expansion of a macro; the macro itself has to provide the quotes. Some builtins return quoted strings, others don't.

A possible solution is a build in macro that takes one argument. It expands this argument fully and returns the quoted expansion.

It will require changes to input handling and macro expansion code.

There is no-one working on this now. Do you want to volunteer?


Module: embedded perl

Perl could be embedded in m4, giving users a powerful programming language for writing macros. A single builtin "perleval" could do the job. First argument could be a perl function and the rest arguments. The return value of the function as a string would be the expansion.

The perl interpreter should be set up when the module is loaded and closed down before m4 exits, using the appropriate hooks in the module interface.

A perl module could potentially give users access to any facility perl has access to, such as databases.

On systems with perl compiled as a shared library the size penalty would be minimal.

(It might not be workable as a module, as it will need to link with non-shared libraries. Don't know how it can be fixed. (RS))

There is no-one working on this now. Do you want to volunteer?


Module: better output control

It has been suggested a couple of times that it should be possible to divert to named files, in order to create several output files.

I think this a bit a misunderstanding. Diversion are inteded to be brought back later, ie, they are temporary and recoverable. Output text, on the other hand, once output it is lost (for m4). Therefore better output control should be made in a different way.

My suggestion is a set of builtins defined by a module:

setoutput(file)
appendoutput(file)
pipeoutput(command)

With these output can be directed better, diversion can be sent to different files, and groups of files can be built by a single m4 run. Calling setoutput without arguments should resume output to standard output.

(Admittedly, diversion 0 (standard output) has always been different, as it cannot be undiverted.)

There is no-one working on this now. Do you want to volunteer?


Module: require/provide functionality

Two new builtins require and provide could provide a handy interface to include. It has proven difficult to write these robustly as normal macros. As an example, the files test.m4 and ../test.m4 could be the same file or different files depending on the search path.

There is no-one working on this now. Do you want to volunteer?