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

[Stan Sutton <suttons@xxxxxxxxxx>]

I think this is a good idea.  The
need to run LPG manually on the checked-out projects has been an obstacle
and a hindrance for a long time.  Let's at least try this as an interim
solution.  

Regards,

Stan

"Robert M. Fuhrer" <rfuhrer@xxxxxxxxxxxxxx>
Sent by: imp-dev-bounces@xxxxxxxxxxx

02/04/2009 09:21 AM

Please respond to
IMP Developers List <imp-dev@xxxxxxxxxxx>

To	IMP Developers List <imp-dev@xxxxxxxxxxx>
cc
Subject	Re: [imp-dev] Bootstrapping IMP.runtime?

We've been seeing some requests to check the generated
files for
the various parsers in IMP (both runtime and meta-tooling)
into the
source repo.

I'm seriously considering this, since, at least until
we get the LPG
builder building parsers on checkout of the grammar file,
having
the generated files already in place definitely simplifies
the
workspace prep process.

Perhaps this is also a solution to the bootstrapping issue
you've
been describing (even though I still think there is no
cycle).

Any other thoughts, or should we just go ahead and start
checking
in the generated parser/lexer implementations?

[Perhaps when we do get the LPG builder performing as
we wish
on all fronts, we *might* remove the generated files.
On the other
hand, that means that our source users will have to *install*
IMP
into their Eclipse before trying to check things out,
or they'll have
to run LPG on the cmd line manually.]

On Jan 22, 2009, at 2:02 PM, Jurgen Vinju wrote:

In the interest of termination, my reply should be shorter
than yours.
That leaves me just the next sentence, which should be short.
I agree, but still. :-)

On Thu, Jan 22, 2009 at 5:01 PM, Robert M. Fuhrer <rfuhrer@xxxxxxxxxxxxxx>
wrote:
But there isn't really a cyclic dependency. You don't
need the
LPG IDE to build the parser, just the parser generator
executable
and the template library.

On Jan 22, 2009, at 3:44 AM, Jurgen Vinju wrote:

Hi!

The bootstrapping is indirect, to use LPG you would use the LPG meta tooling,
which
depends on imp.runtime... You need the LPG meta tooling to compile the
IMP run-time.

Anyways, beer and/or an onion pizza and the time to discuss this... heaven.

As a possible "solution", pdb.values *will* contain several small
parsers for simple data exchange
formats. ATerms is already in there, but I reckon we would add support
for RSF, YAML and S-Expressions too.
Those are easy-to-type formats that are suitable for configuration languages....

The actual reason for these parsers is to be able to easily absorb data
that is produced by existing 
software analysis tools, but hey, who am I to not use a parser for something
it was not intended for?

Cheers,

Jurgen

P.S. you could commit the generated code to break the cyclic dependency
at build time (o no, I actually wrote this, and it will be archived...)

On Thu, Jan 22, 2009 at 12:17 AM, Robert M. Fuhrer <rfuhrer@xxxxxxxxxxxxxx>
wrote:
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.

--
Cheers,
  - Bob
-------------------------------------------------
Robert M. Fuhrer
Research Staff Member
Programming Technologies Dept.
IBM T.J. Watson Research Center

IMP Project Lead (http://www.eclipse.org/imp)
X10: Productivity for High-Performance Parallel Programming
(http://x10.sf.net)
_______________________________________________
imp-dev mailing list
imp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/imp-dev