[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: inserting into tab.h, after %union
From: |
Hans Aberg |
Subject: |
Re: inserting into tab.h, after %union |
Date: |
Wed, 6 Dec 2006 14:16:50 +0100 |
On 6 Dec 2006, at 10:58, Joel E. Denny wrote:
Potentially, but I'm not inclined to complicate the existing
directives as
we grope in the dark trying to accommodate future target
languages that we
haven't even identified yet.
This is what I am saying: you may already have done that by the
current
commands.
As far as these directives being complicated, I just don't think
they are.
Neither did Akim Demaille (who initially proposed the names %
provides and
%requires), Paul Eggert, Paolo Bonzini, and Pupeno when they first
heard
of them. Two months later, Paul said he had forgotten what the
directives
meant, but he made no further comment. Jeff Inman's discomfort seems
quite mild, but I'd be glad to hear further discussion from him.
The problem is not that they are complicated, as they are rather
straightforward, but eneded up with descriptions hard to understand
what they do.
I will say that %code-top is quite specific to C/C++ in my opinion.
So I would suggest to avoid language unification of code placements,
until it is sure it is language independent. Don't know about naming.
If
anything should be converted to a %define, that would be it.
Better to make a new %code, I think. - will tell people what the
command does, in addition to the potential parsing problem.
Also, I must
admit that I added it later without much comment from some of those
people
I mentioned above. Even in C/C++, I don't think it's very commonly
needed, so most people can forget about it.
Especially in C++, there are number of places to put the code, and it
is hard to judge the usefulness of it, without trying it up. So there
is the need for simple skeletin file tweaks, without having to change
the Bison grammar.
I propose to keep language specific, low-level names, until one
can see what
features are language independent, and then succesively replace them.
Well, the %before-header, %start-header, %end-header, and %after-
header
directives were kind of like that before being renamed to the current
directives. However, before Java came up, we were already considering
renaming them because Paul and Akim objected to their language-
specific,
low-level names. I guess you can't please everyone. :)
When I tweaked Bison, I used names (internally in the tweak) like
preamble for code (in the source file) before the union, and
something else for code after it. This is still low level names,
without being too language specific. There, one be reasonably sure,
it is language independent. So therefore, the name "source-file"
perhaps can be avoided. As for the header-file, other languages that
C/C++ may not have it. So in that case, it might be best to bring out
the name "header" in the commands, so the users know that it is for
languages (or C/C++ uses) using a header. That is the principle I
see, anyway.
and the low-level details
vary with the target language.
So what happens if one uses a polymorphic hierarchy, with a
different header
structure to accomodate for that?
I mainly worried getting commands, hard to understand, conflicting
or not
usable with the uses I may need.
Sorry, I don't understand those two sentences.
Im the C++ polymorphic setup, I have a class 'object' maintaining a
pointer to a class 'root' with a reference count. Other types are
derived from the class 'root'. Special rules must be applied to
extract these types, using either static_cast (possible if the type
is known and the root class isn't derived as "virtual") or
dynamic_cast. Now, I think that the Bison setup isn't even designed
for handling redefinition of YYSTYPE. So I do not immediately see
exactly what is needed, and how the current Bison commands will
support that. It could be that they are simply of no use, and it must
be resolved with skeleton tweaks and special code placement macros;
but then it seems silly with special Bison commands for handling the
implementation of the semantic type that cannot this.
But I guess, it can be changed later.
Hans Aberg
- Re: inserting into tab.h, after %union, (continued)
- Re: inserting into tab.h, after %union, Hans Aberg, 2006/12/05
- Re: inserting into tab.h, after %union, Joel E. Denny, 2006/12/05
- Message not available
- Message not available
- Re: inserting into tab.h, after %union, Joel E. Denny, 2006/12/06
- Re: inserting into tab.h, after %union, Hans Aberg, 2006/12/06
- Re: inserting into tab.h, after %union, Hans Aberg, 2006/12/04
- Re: inserting into tab.h, after %union, Joel E. Denny, 2006/12/04
- Re: inserting into tab.h, after %union, Hans Aberg, 2006/12/05
- Re: inserting into tab.h, after %union, Joel E. Denny, 2006/12/05
- Re: inserting into tab.h, after %union, Hans Aberg, 2006/12/06
- Re: inserting into tab.h, after %union, Joel E. Denny, 2006/12/06
- Re: inserting into tab.h, after %union,
Hans Aberg <=
- Re: inserting into tab.h, after %union, Joel E. Denny, 2006/12/06
- Re: inserting into tab.h, after %union, Hans Aberg, 2006/12/07
- Re: inserting into tab.h, after %union, Jeff Inman, 2006/12/06
- Re: inserting into tab.h, after %union, Hans Aberg, 2006/12/06
- Re: inserting into tab.h, after %union, Jeff Inman, 2006/12/06
- Re: inserting into tab.h, after %union, Hans Aberg, 2006/12/06
- Re: inserting into tab.h, after %union, Joel E. Denny, 2006/12/06