| Hi Jurgen,
Although the only thing I like better than onions are onion analogies, there are two flaws in your argument. :-)
It certainly makes sense to differentiate between meta-tools (used at compile or build time), and runtime tools/software (only used at IDE runtime). That distinction still places the generated parser in question in the IMP runtime, however: it's not part of any meta-tooling - it parses preference values that are used at IDE runtime by the tooling for any language. Second, I don't think the bootstrapping notion applies: the component in question is not the result of using IMP. It's the result of using another tool (LPG).
Mind you, I'd like to avoid even the appearance that we're giving preferential treatment to LPG over any other parser generator. The way to do that, though, is to make sure that the meta-tooling and the runtime components make it equally easy to build languages using any parser generator. I just don't think including the results of one particular parser generator in the runtime contradicts that.
Wish we could continue this over a beer... ;-) On Jan 21, 2009, at 4:56 PM, Jurgen Vinju wrote: Hi Bob,
I think I would go for the onion solution ;-) A kernel layer, i.e. IMP run-time that does
not require bootstrapping and has no 'meta tooling' in it.
This is where most of the "heavy lifting" is done, i.e. the
matching of the family of Eclipse API's to "programming language" concepts (API's in
terms of programming language attributes).
A second layers that adds micro-DSL's (like prefspecs) to more effectively/speedily program
with the kernel layer. This layer depends on the kernel layer, and may be generated by the
next one. It also depends on additional libraries, such as the run-times of the next layer.
A third layer that adds specification languages, such as LPG files and such, for generating
the previous layer. This is the high-level meta-tooling layer. This layer depends on the previous
layer and is obviously bootstrapped on it.
I see the kernel layer to be something that is largely a responsibility of the IMP team, although
it is highly flexible, programmable and extensible by the IDE developer.
The second layer is an more open collection of meta tools that hook into the kernel layer, but
still closely related to the features offered by the IMP run-time kernel.
The final layer is completely open, but contains at least the IMP teams most favorite tools.
That's just my thoughts on the subject. Maybe it is just a crude description of what IMP already is?
Groetjes,
Jurgen
On Wed, Jan 21, 2009 at 8:20 PM, Robert M. Fuhrer <rfuhrer@xxxxxxxxxxxxxx> wrote: Hi Jurgen,
I'm not sure what to do about this. On the face of it, your comment about avoiding
LPG dependencies seems entirely reasonable. On the other hand, this basically
implies that no part of IMP can depend on *any* parsing technology. That seems
too restrictive.
I can see where requiring a particular parsing technology for the language-
specific stuff would be *real bad*, and against IMP's basic design goals. I don't
think that runtime dependencies on LPG (or SDF, or ANTLR, or whatever) aren't
a problem.
That said, please remember that we now have the necessary IP approvals for
our dependencies on LPG, and can now distribute the LPG runtime from the
IMP update site. So our users won't have to go to multiple update sites any
more.
In fact, in general, eclipse.org requires that we distribute all non-Eclipse
dependents from the eclipse.org-hosted IMP update site, so this isn't just
the result of our wish for simplicity. On Jan 21, 2009, at 10:12 AM, Jurgen Vinju wrote: Hi guys,
I noticed that a .g file is now part of org.eclipse.imp.runtime, which implies that one needs
LPG meta-tooling to be able to compile the IMP run-time and that the IMP run-time now depends on the LPG run-time.
(import org.eclipse.imp.parser.IParse)
I propose to factor out this dependency in a separate package. Because currently the IMP run-time depends on LPG,
both build-time and run-time, we've introduced a bootstrapping dependency that can be avoided.
Furthermore we burden users of IMP-runtime with an extra dependency. I.e. everybody that uses a
different parsing technology will also have to deploy LPG to their users.
Also, for my development team at CWI, who currently check out IMP run-time without having to install
LPG or LPG meta tooling, this added dependency is an unwanted feature.
|
