PGF service requests are stateless and can run in parallel, but some other
requests handled by the server are not and might even change the current
working directory temporarily, and this affects all threads, so it is
important that the PGF service requests access PGF files by absolute paths.
The interface to the wide coverage translation is in js/gftranslate.js
and it assumes that the grammar is installed on the cloud server
as /robust/Translate8.pgf.
The list of supported languages is hardwired in gftranslate.js, since
there is no support for obtaining this info from the C run-time system
at the moment.
If the C run-time library is compiled and installed on your system, you can now
do 'cabal configure -fc-runtime' to get the following extras:
+ The haskell binding to the C run-time library will be included in the
PGF library (so you can import it in Haskell applications).
Documentation on the new modules will be included when you run
'cabal haddock'.
+ The new command 'pgf-shell', implemented on top of haskell binding to
the C run-time system.
+ Three new commands in the web API: c-parse, c-linearize and
c-translate. Their interfaces are similar to the corresponding commands
without the "c-" prefix, but they should be considered preliminary.
* The haskell-bind.cabal file makes it easy to build the haskell binding and
use it in ghci.
* pgf-shell.hs is a simple example of how to use the haskell binding.
Change the type of getConcr from
getConcr :: PGF -> Language -> Concr
to
getConcr :: PGF -> Language -> Maybe Concr
This is to prevent programs from crashing later if you try to select a
concrete syntax that is not present in a grammar.
When running a command like
gf -make L_1.gf ... L_n.gf
gf now avoids recreating the target PGF file if it already exists and is
up-to-date.
gf still reads all required .gfo files, so significant additional speed
improvements are still possible. This could be done by reading .gfo files
more lazily...
When running a command like
gf -make -name=T L_1.pgf ... L_n.pgf
gf now checks if T.pgf exists and is up-to-date before reading and computing
the union of the L_i.pgf files.
The name (T) of the target PGF file has to be given explicitly for this to work,
since otherwise the name is not known until the union has been computed.
If the functions for reading PGF files and computing the union were lazier,
this would not be necessary...
Some backwards incompatible changes were made to the PGF file format after
the release of GF 3.5. This patch adds a module for reading PGF files in the
old format.
This means that old PGF files on the grammaticalframework.org server will
continue to work after we install the latest version of GF.
There were two differences between the current output and the old gold file:
1. The trees are no longer generated with increasing depth
2. The meaning of the -depth flag has changed: for example,
"gt -cat=Nat -depth=1" used to generate only "zero",
now you also get "succ zero".
