I prefer small functions with descriptive names over large monilithic chunks
of code, so I grouped the compiler passes called from compileSourceModule
into funcitons named frontend, middle and backend. This also makes decisions
about which passes to run clearly visible up front.
Also made some small changes in GF.Compile.
The -path flags in the RGL modules compiled during 'cabal build' now refer
directly to the needed source directories. References 'alltenses' and 'present'
(and the nonexistent directory 'mathematical') have been removed.
This allows the files to be compiled in any order (e.g. in parallel). In
addition, you can do things like
gf -retain lib/src/api/TrySwe.gf
without compiling/installing any other RGL modules first, and without
setting any other path flags or environment variables.
In particular, the function compileOne has been moved to the new module
GF.CompileOne and its type has been changed from
compileOne :: ... -> CompileEnv -> FilePath -> IOE CompileEnv
to
compileOne :: ... -> SourceGrammar -> FilePath -> IOE OneCompiledModule
making it more suitable for use in a parallel compiler.
The RGL is now compile with only three calls to GF (prelude, present,
alltenses). This also makes even more parallelism available to GF for speeding
up full builds of the RGL.
The def rules are now compiled to byte code by the compiler and then to
native code by the JIT compiler in the runtime. Not all constructions
are implemented yet. The partial implementation is now in the repository
but it is not activated by default since this requires changes in the
PGF format. I will enable it only after it is complete.
This speedup is obtained by instead of generating 211 shell commands to compile the RGL one file at a time, generate 7 shell commands, passing a number of
related files to GF in one go.
In addition to cutting down the zero build time, this opens up for speeding up
full builds of the RGL, by adding more parallelism in GF's grammar compilation
machinery.
(Note: gf.cabal already takes advantage of GHC's parallel build option to
speed up the compilation of GF itself, if GHC>=7.8 is used.)
GF.Text.Pretty provides the class Pretty and overloaded versions of the pretty
printing combinators in Text.PrettyPrint, allowing pretty printable values to
be used directly instead of first having to convert them to Doc with functions
like text, int, char and ppIdent. Some modules have been converted to use
GF.Text.Pretty, but not all. Precedences could be added to simplify the pretty
printers for terms and patterns.
GF.Infra.Location contains the types Location and L, factored out from
GF.Grammar.Grammar, and the class HasSourcePath. This allowed the import
of GF.Grammar.Grammar to be removed from GF.Infra.CheckM, making it more
like a pure library module.
Detected when building today:
Building gf-3.6...
Preprocessing library gf-3.6...
src/runtime/haskell/PGF/Internal.hs:17:8:
Could not find module ‘Data.Binary.IEEE754’
It is a member of the hidden package ‘data-binary-ieee754-0.4.4’.
Perhaps you need to add ‘data-binary-ieee754’ to the build-depends in your .cabal file.
When using full=yes in the web service 'complete' command,
you now get an additional field 'seq' with the longest possible completion.
So, given:
lin
f1 = ss "the" ;
f2 = ss ("the red house" | "the real deal") ;
and trying to complete on input "th", you get:
[
{
"from": "TestCnc",
"brackets": {
"cat": "_",
"fid": 0,
"index": 0,
"fun": "_",
"children": []
},
"text": "th",
"completions": [
{
"token": "the",
"funs": [
{
"fun": "f1",
"hyps": [],
"cat": "C",
"seq": "the"
},
{
"fun": "f2",
"hyps": [],
"cat": "C",
"seq": "the red house"
},
{
"fun": "f2",
"hyps": [],
"cat": "C",
"seq": "the real deal"
}
]
}
]
}
]
