Skip to content

Final 21

Pre-release
Pre-release
Compare
Choose a tag to compare
@Ingo60 Ingo60 released this 09 Apr 15:56
· 1870 commits to master since this release

This is the final release of the 3.21 branch, and serves as fallback (just in case ...), it is also the starting point for the 3.22 releases that will result in an overhauled compiler.

The goals are thus:

  • Scanner must not load classes. Because of this, precedence and associativity of operators will not be known to the parser.
  • Parser will not: desugar do-blocks and list comprehensions, translate expressions to patterns and will not resolve applications with binary operators. A new source expression type will be needed for this.
  • Benefit: Desugaring pass and instance derivation does not need to distinguish between expressions and patterns, which should reduce the support code by 50%.
  • Desugaring happens only after import pass, together with name resolution. At this point, the symbol tables of the imported modules are known, which contain operator information n the associated symbols. This will solve also the long standing problem that operator names appear "global", i.e. you can't have two operators with the same name but different associativity and precedence in different modules, without the compiler choosing silently one of the associativities/precedences. Also, these properties can be documented/shown in the IDE.
  • Every pass will be of type StateT IO Global. Most passes will not do IO, however. (Scanner, Import, and code generation, of course, must be able to do IO, as well as future plug-ins). Error messages are saved in the state and are printed at the end of the pass. (Trace output will use trace/traceLn, not IO)
  • The monolithic big source files (like Transform.fr, that contains 4 different passes) will get splitted up.
  • A better make facility will do a dependency analysis of the given source files and compile in parallel, if possible. We will cache the global state, not the annotations from the class files. The latter prooved to be buggy in the presence of certain changes: when B depended on A and A was changed, this loaded the old A.class, then compiled A, then tried to compile B. But in B's import pass, the old A class was still there, so compilation terminated with phantom errors: errors that went away by just restarting the compilation (because then, the new A.class could be loaded). This also makes the import independent with regard to the source of the global state of imported modules: if it was compiled or imported before, the available state can be used, and only if it was not imported before and not build in the same session will the class file get loaded and the global state reconstructed. This will make it possible to javac the produced java files in one go, which could again be faster than now.