[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Naming conventions for skeletons
From: |
Akim Demaille |
Subject: |
Naming conventions for skeletons |
Date: |
04 Jun 2002 15:58:27 +0200 |
User-agent: |
Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Honest Recruiter) |
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.
- Naming conventions for skeletons,
Akim Demaille <=