bug-bison
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Multiple output


From: Hans Aberg
Subject: Multiple output
Date: Sun, 2 Jun 2002 20:44:46 +0200

>The Bison team is happy to present its 1.49a snapshot.
...
>  ftp://alpha.gnu.org/gnu/bison/bison-1.49a.tar.gz   (862 kB)
>  ftp://alpha.gnu.org/gnu/bison/bison-1.49a.tar.bz2  (708 kB)

I had a look on how the M4 invokation is hooked up, and I will describe a
bit how that relates to my ideas:

The main point is that the system 1.49a is easy to generalize so that one
is not dependent on M4 specifically. This generalization may be needed when
multi-language support should be facilitated, but also in order to support
experimentation with other post-processor systems.

This can be done by developing a mini-language for the skeleton file, which
can be successively enhanced as the need arrives. When I experimented with
this idea, I drew the conclusion that macro-languages are a bad idea;
instead it is better to use strings as manipulated objects. For strings, I
chose the `...' syntax, in order to make C-code easy to write (so that a
C-strings would appear as say `"..."' with the outer quotes belonging to
the skeleton language and the inner quotes a part of what is written as
C-code).

In file output.c, output() writes a temporary file, which culminates in the
invokation of M4 by the lines:
  skel_in = readpipe (m4,
    "-I", bison_pkgdatadir,
    "m4sugar/m4sugar.m4",
    tempfile,
    skeleton,
   NULL);

The first step towards a skeleton language would be to replace this with a
controlling command that is put into the skeleton file, for example
  post-process { m4,
    `-I', bison_pkgdatadir,
    `m4sugar/m4sugar.m4',
    tempfile }
When Bison sees this command, it creates a temporary file, which is then
fed to a program according to instructions. The names m4, bison_pkgdatadir,
etc., could be strings, but also predefined names in the skeleton file
language (in which case one can make them modifiable via program arguments
or .y file commands).

Then file output.c, output_skeleton() outputs the actions into the
temporary file by the lines:
  fputs ("m4_define([b4_actions], \n[[", out);
  actions_output (out);
  fputs ("]])\n\n", out);

For the skeleton file mini-language, one might use a syntax like
  write tempfile {`m4_define([b4_actions], \n[[' actions `]])\n\n'}

The main point here is that "actions" could at first be a predefined word
in the language, but later on, when multi-language requirements come along,
one could break it up into smaller components (so that alternative
translations for say $x becomes available). It then does not remain whether
the key-word "actions" remains or not, so it is easy to make an upwards
upgradable path.

One could add a command like:
  input file_name
This might be useful in the multi-language picture, for example, in order
to ensure that the comments are the same, by putting them all in the same
file, which is then included by the various language specialization files.

And so on.

  Hans Aberg





reply via email to

[Prev in Thread] Current Thread [Next in Thread]