gf-core.git/src/compiler/GF/CompileInParallel.hs, branch optimize

define return in terms of pure, >> as *>, mappend as <>

2025-08-02T14:39:31+00:00

In preparation for deprecation, see https://gitlab.haskell.org/ghc/ghc/-/wikis/proposal/semigroup-monoid and https://gitlab.haskell.org/ghc/ghc/-/wikis/proposal/monad-of-no-return

add whitespace on list comprehensions, applications etc.

2025-08-02T14:39:31+00:00

text editor interprets these things as errors (e.g. unterminated qq for list comprehension) and underlines red, even though there is no real error.

MonadFail: Make backwards-compatible

2020-09-05T18:23:07+00:00

Fix most build errors

2020-08-05T16:48:24+00:00

more dead code

2019-09-20T14:15:28+00:00

GF_LIB_PATH can now be path1:path2:path3, not just path1

2018-07-22T07:04:07+00:00

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

Fixes for GHC 8.4.1 compatibility

2018-04-18T17:18:10+00:00

* 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)

Parallel compilation: "gf -make -j" and "gf -make -j=n" now work as expected

2015-09-11T14:18:01+00:00

* "gf -make -j=n" uses n parallel threads. * "gf -make -j" adapts to the number of processors in the system. This mimics how "cabal build -j" and "ghc --make -j" works. Support for this is implemented in the new module GF.System.Concurrency and it depends on the function Control.Concurrent.setNumCapabilities, which is only available in GHC>=7.6 (base>=4.6). GF can still be compiled with GHC<7.6, but then you have to use +RTS -N -RTS to take advantage of multicore processors. To detect the number of processors in the system, the code depends on a foreign import of a C function in the GHC run-time system.

Bump version of .gfo and .pgf files, improve error messages on version mismatch

2015-06-23T12:58:14+00:00

Becacuse of the new special tokens added to the Symbol type, .gfo and .pgf files produced with the current version of GF can not always be used with older versions of GF and the PGF run-time system. The PGF version number was increased from (2,0) to (2,1). GF can still read version (2,0) and (1,0), so old PGF files continue to work. The GFO version was increased from "GF03" to "GF04".

GF.CompileInParallel: get rid of the cryptic 'thread blocked indefinitely in an MVar operation' message after compilation errors

2015-03-31T13:26:51+00:00

Instead show a message saying how many modules were affected by the compilation errors.