Re: [imp-dev] Bootstrapping IMP.runtime?

[Jurgen Vinju <jurgen@xxxxxxxxx>]

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.

Cheers,

 - Bob

_______________________________________________
imp-dev mailing list
imp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/imp-dev