Naming conventions for skeletons

[Akim Demaille]

Hi!

Before the integration of GLR, I think we should settle some
conventions over the skeleton names.

The constraints I wish we could handle are the following:

1 avoid escaping from 8+3 file names unnecessarily
  as it causes gratuitous problems to our poor fellows.
  I guess Paul E. won't agree too much about this point :)

2 avoid having to compute skeleton names from various bits
  as it may cause additional problems related to the previous point.

3 encode the algorithm used

4 encode the output language

5 make some provision for alternative skeletons.
  For instance, I would also like to make some measurements with
  things such as non compressed tables: some authors report good
  performances with a straight encoding of the LALR tables without the
  current compaction scheme.  So some provision for such cases
  could be pleasant.


In particular, wrt point 2, I'm not sure I want to have something like

%language="c++"
%glr

Rather, I would prefer having some simpler, i.e.,

        %skeleton="glalr1.c++"

It simplifies many things, in particular it frees us from having a
table somewhere mapping the various combinations to a 8+3 file name.
I can hear Paul E. coming and suggesting that we could simply have

        ALGO[-VARIATION].EXT

with ALGO       \in drlr1, lalr1, glr1 etc.
     VARIATION  \in push, bfisher etc.
     EXT        \in c, cc, java, scm etc.

or maybe

        ALGO[-VARIATION]-LANGUAGE.bis

with LANGUAGE   \in C, CC, Java, Scheme etc.

but I'd like to make it simple for the short file name systems.  ``I'd
like'' stands for ``it wouldn't be too hard convincing me'', agreed.

But maybe there are better schemes?  Maybe we should take advantage of
directories?  %skeleton='c/glalr1'?



Or maybe all this is overkill and everybody will be happy with
%skeleton only, and a table of names in the documentation, such as:

        yacc.c      the current bison.simple, i.e., the default
        lalr1.c++   the current bison.c++
        glalr1.c    the forthcoming skeleton from Paul H.
        btyacc.c & btyacc.cc if we do swallow BTYacc some day
        drlr1.c     if Carlos Javier Borges Villalba really makes it.
        etc.

Note that some variations also induce variations in the behavior of
Bison.  For instance, s/r and r/r are far less important in the
context of btyacc, or glalr, and don't cause hard errors.  DRLR uses
completely different tables, so bison-the-table-generation has to be
warned in some way.  Hence even we %skeleton="glalr.1", we'd need an
additional %glr or so.

As you can see, it's far from being clear to me.  I'd really
appreciate other thoughts.