Proposed refactoring in rascal-core to facilitate first iteration of compiler release.

[jurgenvinju]

1. rascal-core is an experimental project containing: (1) the type-checker and (2) the compiler and (3) part of the run-time of compiled code
2. we might soon want to start using compiled code in experimental (but deployed) settings
3. this proposal is to make sure this is possible and future changes to the compiler and the run-time are versioned and tractable.

The idea is to promote the "experimental" run-time classes of the compiler to production code in a number of easy steps:

1. rename the package inside rascal-core from org.rascalmpl.core.library.lang.rascalcore.compile.runtime to org.rascalmpl.runtime and move everything to this location
2. update the Java code generator in the compiler to reflect the new package location
3. remove any unused classes and methods from that package
4. test the new version of the compiler and the run-time on the tests, the parser generator and typepal
5. now move org.rascalmpl.runtime to the rascal project (removing the code from rascal-core)
6. release a RC of the rascal project and let rascal-core depend on this.

The effect is that downstream releases of the rascal project will provide a fully functional environment for compiler Rascal code, even if this compilation is experimental and triggered manually from the rascal-core project.

The plan is to (much) later also move the entire type-checker and compiler back to the rascal project. This is when we could produce a REPL for compiling Rascal and running compiled Rascal code. However, there are still many choices there (do we run the bootstrapped compiler or an interpreted one?) etc.

If we in a later stage think it's a good idea to separate the run-time, including a lot of stuff from the current rascal project, into another project (rascal-runtime), this is still possible. However, when we remove the interpreter from rascal, then this is exactly what is left in the rascal project. I think I would be in favor of this for other reasons as well.

Anyway: rename the run-time in rascal-core, move it to rascal, release it. That's the plan.

[DavyLandman]

I roughly agree with this plan, but the last part about moving runtime to a separate jar is still useful, as this would make it a lot easier to have compiled programs not carry around the rascal compiler.

As in, if I deploy a rascal application, in most cases I don't need the rascal compiler. I only want the runtime system (and maybe the lib, as long as it's a lot smaller than it's now).

[jurgenvinju]

Sure; let's talk about that later. It's a complex story that we'll need to figure out. For now the focus is on getting there first three bootstraps done and that requires optimal simplicity and tractability.

[jurgenvinju]

Then we'll build the new repl. Then we can optimize for download size maybe?

[PaulKlint]

I concur with the above ideas. Let's do this in stages and let's try to preserve the version history.

[DavyLandman]

Renames by default cause version tracking problems for git. I mean, you can for a specific git command on the shell ask for it to use a heuristic to detect renames, but all the default tooling (like github) will ignore those in a blame or any other overview.

I can help get all the intermediate commits that do something to the directory were interested into rascal, with some creative rewriting, but after the rename, it will require extra steps for any tool to reach those old commits.

[jurgenvinju]

It's most important that the history is stored, which it is. If we need to look into the history we can. Let's not make it more complicated than that. We need to be able to go back to earlier versions and run them and inspect them. Git offers that out of the box.

[jurgenvinju]

If we want version history in the files when we move them to the other project, I think we are in for a too much work than we have time for right now, with too few benefits. Imho.