| Age | Commit message (Collapse) | Author |
|---|
|
Also remove ununsed GF.Compile.PGFtoAbstract
|
|
|
|
|
|
|
|
TODO: better treatment of Predef functions and record subtyping coercions
|
|
+ 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).
|
|
+ Hide Prelude.<> to avoid ambiguity with ghc-8.6
+ Vertical alternative in the pretty printer for table types A => B
|
|
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...
|
|
This should make it easier to use GF with UTF-8 in the Windows Console
See https://groups.google.com/forum/#!topic/gf-dev/DCou6FDhCnU
|
|
E.g. `foldWithKey` has been deprecated since 0.4.0.0 (November 2010)[1] and has been removed in 0.6.0.1 (2018)[2]
[1]: https://github.com/haskell/containers/blob/master/changelog.md#0400--nov-2010
[2]: https://github.com/haskell/containers/blob/master/changelog.md#death-of-deprecated-functions
(commit originally by @fredefox)
|
|
This reverts commit 69cea20dac8ac73fa0a61ed4ff427d2524ee253b.
|
|
|
|
|
|
|
|
The functions cExpr and hsExpr in GF.Command.Commands2 need to
handle string literals.
|
|
|
|
Traditionally, GF_LIB_PATH points to something like
`.../share/ghc-8.0.2-x86_64/gf-3.9/lib`
and if you want prelude and alltenses and present, you add a
`--# -path=.:present`
compiler pragma to the top of your .gf file
But if you are developing some kind of application grammar
library or contrib of your own, you might find yourself
repeating your library path at the top of all your .gf files.
After painstakingly maintaining the same library path at the
top of all your .gf files, you might say, let's factor this
out into GF_LIB_PATH.
Then you might then find to your surprise that GF_LIB_PATH
doesn't accept the usual colon:separated:path notation
familiar from, say, unix PATH and MANPATH.
This patch allows you to define
`GF_LIB_PATH=gf-3.9.lib:$HOME/gf-contrib/whatever/lib`
in a more natural way.
If you are an RGL hacker and have your own version of the
RGL tree sitting somewhere, you should be able to have both
paths in the GF_LIB_PATH, for added convenience. This minor
convenience will probably lead to obscure bugs and great
frustration when you find that your changes are mysteriously
not being picked up by GF; so keep this in mind and use it
cautiously.
This caution should probably sit in the documentation
somewhere. A subsequent commit will do that.
If you use zsh, you can do this to quickly build up a big
GF_LIB_PATH:
% gf_lib_path=( $HOME/src/GF/lib/src/{api,abstract,common,english,api/libraryBrowser,prelude,..} )
% typeset -xT GF_LIB_PATH gf_lib_path
|
|
|
|
One could also add stricter version constraints in gf.cabal, e.g.
base>=4.8 (implies GHC>=7.10) if we want to only support building with
GHC>=7.10.
|
|
|
|
* 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)
|
|
gf -server now includes the comment field from the grammar in the
response to /cloud requests with command=ls-t and ext=.json
|
|
The warning is about a change that was made in GF 3.6 (June 2014) and has
probably outlived its purpose by now.
|
|
|
|
|
|
|
|
|
|
|
|
the parser in the Haskell runtime. This is also reflected in all bindings.
|
|
|
|
|
|
|
|
TreeOperations
|
|
|
|
internal module in the runtime. These are not really part of the core runtime.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Haskell runtime
|
|
|
|
|
|
|
|
|
|
|
|
|
|
standard shell
|
|
|
