The userLangauge is the name of the concrete syntax that has a languageCode
that matches the user's preferred language, as reported by the web browser.
If no matching language code is found, the PGF service now sets userLanguage
to the concrete syntax for English (e.g. FoodsEng) if present, and defaults
to the first concrete syntax (e.g. FoodsAfr) only if English is not present
in the grammar.
A preferred grammar is selected when a user visits the Minibar for the
first time. (Like before, Minibar remembers the selected grammar for future
visits.)
A preferred list of grammars can be specified in config.js in the .../minibar
directory on the server, e.g. like this:
preferred_grammars=["/grammars/Foods.pgf","/grammars/ResourceDemo.pgf"]
The first available grammar from the list is used.
When you press the "i" or "More info" button for a grammar, the info now
includes a link that can be used by anyone to open this specific grammar in
the minibar.
The documentation is taken from a file called Grammar.pgf_info, located
next to the Grammar.pgf file on the server.
The first line of the documentation is displayed below the menu bar in
the minibar. The rest of the documentation is displayed when you press
the "More info" button (or the "i" button).
The documentation can contain HTML markup. Blank lines are treated as
paragraph breaks.
It was only needed for compatibility with directory<1.2, but
directory>=1.2 has been shipped with ghc since ghc-7.6.
Note: time-compat-1.9.* (the current version) is a completely different
package, that does not provide the needed function toUTCTime, which
was provided in time-compat-0.1.*.
grammar.js contained only one langauge: FoodsEng. Now it contains
FoodsEng and FoodsIta, similar to what's shown in the gf-tutorial.
The grammar comes from gf-contrib/tutorial/foods.
After fixing trivial problem in translator.html, the demo works, but
the example grammar contains only one langauge, so it is not so
interesting. translator.html is located in src/runtime/javascript.
The editor.html in the same location also works.
e.g. if C is a fun and not a cat in the abstract syntax.
Discarding bad lincats prevents GF from generating malformed PGFs that
are rejected by the C run-time system.
I also added code to reject bad lincats with an error, but I left it
commented out since it seems a bit pedantic compared to GF's otherwise
rather sloppy grammar checking.
The problem was that the RGL was both built and copied to the destdir
during the build step, which caused it to be deleted before the install
step. It is now copied to destdir during the install step.
+ Abstract syntax now is converted directly from the Grammar and not via PGF,
so you can use `gf -batch -no-pmcfg -f canonical_gf ...`, to export to
canonical_gf while skipping PMCFG and PGF file generation completely.
+ Flags that are normally copied to PGF files are now included in the
caninical_gf output as well (in particular the startcat flag).
This output format converts a GF grammar to a "canonical" GF grammar. A
canonical GF grammar consists of
- one self-contained module for the abstract syntax
- one self-contained module per concrete syntax
The concrete syntax modules contain param, lincat and lin definitions,
everything else has been eliminated by the partial evaluator, including
references to resource library modules and functors. Record types
and tables are retained.
The -output-format canonical_gf option writes canonical GF grammars to a
subdirectory "canonical/". The canonical GF grammars are written as
normal GF ".gf" source files, which can be compiled with GF in the normal way.
The translation to canonical form goes via an AST for canonical GF grammars,
defined in GF.Grammar.Canonical. This is a simple, self-contained format that
doesn't cover everyting in GF (e.g. omitting dependent types and HOAS), but it
is complete enough to translate the Foods and Phrasebook grammars found in
gf-contrib. The AST is based on the GF grammar "GFCanonical" presented here:
https://github.com/GrammaticalFramework/gf-core/issues/30#issuecomment-453556553
The translation of concrete syntax to canonical form is based on the
previously existing translation of concrete syntax to Haskell, implemented
in module GF.Compile.ConcreteToHaskell. This module could now be reimplemented
and simplified significantly by going via the canonical format. Perhaps exports
to other output formats could benefit by going via the canonical format too.
There is also the possibility of completing the GFCanonical grammar
mentioned above and using GF itself to convert canonical GF grammars to
other formats...
* In GHC 8.4.1, the operator <> has become a method of the Semigroup class
and is exported from the Prelude. This is unfortunate, since <> is also
exported from the standard library module Text.PrettyPrint, so in any
module that defines a pretty printer, there is likely to be an ambiguity.
This affects ~18 modules in GF. Solution:
import Prelude hiding (<>)
This works also in older versions of GHC, since GHC does't complain if
you hide something that doesn't exists.
* In GHC 8.4.1, Semigroup has become a superclass of Monoid. This means
that anywhere you define an instance of the Monoid class you also have to
define an instance in the Semigroup class.
This affects Data.Binary.Builder in GF. Solution: conditionally define
a Semigroup instance if compiling with base>=4.11 (ghc>=8.4.1)
The editor doesn't show delete buttons on grammars published by other
users, but it was too picky when deciding which grammars you own. Now
it should be possible to delete grammars from the device/browser
you published it from, even if you don't have a private copy of it any more.
On a related note, there seems to be problem with the way unique grammars
names are created and maintained, causing published grammars to be duplicated
in some cases. This needs to be overhauled.
This was a problem in Safari (an other similar browsers I presume), but
not in Firefox: hovering over the grammar comment (shown below the grammar
name when you edit a grammar) didn't reveal the button to edit it, thus
preventing you from adding a comment. It was till possible by selecting the
"Enable editing on touch devices." at the bottom of the screen, but most
people probably didn't notice that it is possible to add a comment.
Cabal>=1.20 allows control over parallelism when compiling grammars from
Setup.hs and WebSetup.hs.
base>=4.6 allows conditional compilation with CPP to be eliminated from
a few modules.
base-4.6 corresponds to GHC 7.6.3, which is what you get in
Debian 8 (aka jessie, aka oldstable) from 2015.
Thomas Hallgren