1
0
forked from GitHub/gf-core
Commit Graph

324 Commits

Author SHA1 Message Date
krasimir
f848857519 added option -plus-as-bind which treats (+) as a bind when used with runtime variables 2015-02-20 13:26:12 +00:00
hallgren
54ae70a81e Changes for compatibility with ghc-7.10-rc2
2 modules: Name clashes caused by Applicative-Monad change in Prelude
2 modules: Ambiguities caused by Foldable/Traversable in Prelude
2 modules: Backwards incompatible changes in time-1.5 for defaultTimeLocale
9 modules: {-# LANGUAGE FlexibleContexts #-} (because GHC checks inferred types
           now, in addition to explicitly given type signatures)

Also silenced warnings about tab characters in source files.
2015-02-16 15:05:06 +00:00
hallgren
efb1b540f4 Translating linearization functions to Haskell: more simplifications
+ Some additional simplifying rewrites.
+ Use an intermediate representation for Haskell types, for separation of
  concerns and cleaner code.
+ Pretty printer layout tuning
+ Code cleanup.
2015-02-12 16:05:48 +00:00
hallgren
63f79fb250 Translating linearization functions to Haskell: simplify the generated Haskell code
Introduced an intermediate representation for the generated Haskell expressions.
This allows pretty printing concerns to be separated from conversion concerns,
and makes it easy to apply some simplifying rewrites to the generated
expressions, e.g.

	[x] ++ [y]    ==> [x,y]
	pure f <*> x  ==> f <$> x
	f <$> pure x  ==> pure (f x)
	join (pure x) ==> x
2015-02-11 23:50:19 +00:00
hallgren
8e4e8da105 Translating linearization functions to Haskell: support for variants
By adding the flag -haskell=variants to the command line, GF will now generate
linearization functions in Haskell that support variants. Variants are
represented as lists in Haskell.

Variants inside pre { ... } expressions are still ignored.

TODO: apply some monad laws to generate more compact code (using an
intermediate representation of the generated Haskell code, instead of
pretty printing directly from the GF code).
2015-02-09 16:24:33 +00:00
hallgren
7e1120d271 Translating linearization functions to Haskell: move a common record type to PGF.Haskell
Move the Haskell representation of the common linearization type {s:T} to the
shared module PGF.Haskell, so that the same overloaded projection function
proj_s can be used for all concrete syntaxes.
2015-01-19 12:43:32 +00:00
hallgren
20b271a238 Translating linearization functions to Haskell: better treatment of special tokens
Common code has been lifted out from the generated Haskell modules to
an auxiliary module PGF.Haskell, which is currently included in the
regular PGF library, although it is independent of it and probably belongs
in a separate library.

The type Str used by linearization functions is now based on a token
type Tok, which is defined in PGF.Haskell.

PGF.Haskell.Tok is similar to the type GF.Data.Str.Tok, but it has
constructors for the special tokens BIND, SOFT_BIND and CAPIT, and there is
a function

	fromStr :: Str -> String

that computes the effects of these special tokens.
2015-01-14 14:35:39 +00:00
hallgren
2e642ace8a Translating linearization functions to Haskell: add support for pre {...}
STILL TODO:

	- variants
	- better treatment of special tokens BIND, SOFT_BIND & CAPIT.
2015-01-08 17:52:45 +00:00
hallgren
ef84f7d842 Translating linearization functions to Haskell: use qualified names to avoid name clashes
All languages in the Phasebook can now be converted to compilable Haskell
code.

STILL TODO:
  
  	- variants
  	- pre { ... }
2015-01-07 16:13:28 +00:00
hallgren
0694a915d2 Translating linearization functions to Haskell: significant code size reductions
+ Instead of including lists of parameter values generated by GF, generate
  code to enumerate parameter values (in the same order as GF). This seems
  to give a factor of 2-3 code size reduction in the Phrasebook (e.g.
  from 84MB to 25MB for Hin, from 338MB to 154MB for Fre).

+ Deduplicate table entries, i.e. convert "table [..,E,..,E,..,E,..]" into
  "let x = E in table [..,x,..,x,..,x,..]". This gives even more significant
  code size reduction in some cases, e.g. from 569MB to 15MB for
  PhrasebookFin.

All phrasebook languages can now be converted to compilable Haskell code,
except PhrasebookPes, which still has the name clash problem.
2015-01-06 19:57:24 +00:00
hallgren
cbd873839b More work on translating linearization functions to Haskell
Many Phrasebook languages can now be converted to compilable Haskell code.
Some languages (Fre, Hin, Snd, Urd) generate too much Haskell code to be
practically useful (e.g. 338MB for Fre). One language (Fin) took too long
to convert to Haskell. One language (Pes) has problems with name clashes in
the generated Haskell code.

STILL TODO:

  	- variants
  	- pre { ... }
  	- reduce code duplication for large tables
	- generate qualified names to avoid name clashes
2015-01-06 16:48:03 +00:00
hallgren
2eaf46f610 Work in progress on translating linearization functions to Haskell
The translation is currently good enough to translate all concrete syntaxes
of the Foods and Letter grammars, and some concrete syntaxes of the Phrasebook
grammar (e.g. PhrasebookEng & PhrasebookSpa works, but there are problems with
e.g. PhrasebookSwe and PhrasebookChi)

This functionality is enabled by running

	gf -make -output-format=haskell -haskell=concrete ...

TODO:
	- variants
	- pre { ... }
	- eta expansion of linearization functions
	- record subtyping can still cause type errors in the Haskell code
	  in some cases
	- reduce code large tables
2014-12-11 16:08:36 +00:00
hallgren
676b0d6e81 Haddock documentation: expose exportPGF, some other small improvements 2014-12-08 14:48:14 +00:00
hallgren
fc46db8c7f Eliminate the record extension operator from the Value type returned by the partial evaluator
It was used only in cases where a lock field needed to be added to a
run-time variable, like e.g. in examples/phrasebook/SentencesTha.gf: 

    lin
      PGreetingMale g   = mkText (lin Text g) (lin Text (ss "ครับ")) | g ;
      PGreetingFemale g = mkText (lin Text g) (lin Text (ss "ค่ะ")) | g ;

But lock fields are only meaningful during type checking and can safely be
ignored in later passes.
2014-12-05 12:42:17 +00:00
kr.angelov
b1e6a21c56 now (+) in the abstract syntax works, i.e. it knows how to deal with partial sums 2014-10-31 14:16:11 +00:00
kr.angelov
9b0f354c7c a more efficient tail call by using the new TUCK instruction 2014-10-30 13:09:50 +00:00
kr.angelov
efedec187c an explicit SAVE instruction 2014-10-26 11:40:12 +00:00
kr.angelov
c8b3865338 an explicit PUSH_FRAME instruction 2014-10-22 14:11:41 +00:00
hallgren
391b301881 ModuleName and Ident are now distinct types
This makes the documentation clearer, and can potentially catch more
programming mistakes.
2014-10-21 19:20:31 +00:00
aarne
f6441b2292 use of 'head' in TypeCheck/RConcrete created an uncomprehensible error message. Now checking for the emptiness of the list concerned, so that the error can be found. 2014-10-20 20:06:46 +00:00
hallgren
55aebadd5a Remove some dead code
* The following modules are no longer used and have been removed completely:

	GF.Compile.Compute.ConcreteLazy
	GF.Compile.Compute.ConcreteStrict
	GF.Compile.Refresh

* The STM monad has been commented out. It was only used in
  GF.Compile.SubExpOpt, where could be replaced with a plain State monad,
  since no error handling was needed. One of the functions was hardwired to
  the Err monad, but did in fact not use error handling, so it was turned
  into a pure function.

* The function errVal has been renamed to fromErr (since it is analogous to
  fromMaybe).

* Replaced 'fail' with 'raise' and 'return ()' with 'done' in a few places.

* Some additional old code that was already commented out has been removed.
2014-10-20 15:05:43 +00:00
hallgren
6375bacc73 Some work on the haddock documentation 2014-10-16 16:28:54 +00:00
hallgren
c924491289 More haddock documentation improvements 2014-10-16 14:03:57 +00:00
kr.angelov
26ad164cec finally proper stack unwind in the evaluator 2014-10-16 10:00:32 +00:00
hallgren
393dde2eb9 Fixes for the haddock documentation 2014-10-15 20:42:36 +00:00
kr.angelov
ac288386c4 the compiler now allows + to be used as a floating point addition in the abstract syntax 2014-10-14 11:15:18 +00:00
kr.angelov
b5cc77aea1 yet another bugfix in the byte code 2014-10-14 10:39:28 +00:00
kr.angelov
37bd8dd9fd another bugfix in the byte code generation 2014-10-14 09:43:43 +00:00
kr.angelov
f4dc2c0b6e bugfix in the bytecode generator 2014-10-14 09:27:24 +00:00
kr.angelov
f8b73d593c Prelude.CAPIT is now a built-in primitive. It still generates &| in the Haskell runtime but will be intepreted in the C runtime 2014-10-09 19:34:12 +00:00
kr.angelov
9c2f71b07a now we statically allocate closures for all top-level functions and all nullary constructors. closures are dynamically allocated only for CAFs. this reduces memory use and time to allocate dynamic closures 2014-10-08 12:57:29 +00:00
kr.angelov
35333385b6 bugfix in the byte code compiler 2014-10-07 20:03:54 +00:00
kr.angelov
13c7721bc5 using instruction RET was wrong; now use EVAL 2014-10-06 15:57:42 +00:00
kr.angelov
f70eecb63c minor stylistic change in GenerateBC 2014-09-29 15:08:00 +00:00
kr.angelov
80acad4447 bugfix in the pattern matching compiler and a number of other fixes that I somehow did not push before 2014-09-29 15:00:04 +00:00
aarne
aef787aeb1 checked that course of value tables (table P [...]) have the correct number of values w.r.t the type P. This was previously not checked, and caused hard-to-find run-time errors. 2014-09-27 17:14:35 +00:00
kr.angelov
3ced115807 forgot to type check the type of a typed let expression 2014-09-17 22:25:08 +00:00
kr.angelov
a5f81ff81c the type checker for the abstract syntax now allows let expressions in def rules, since they are easily compilable to byte code. This fails in the Haskell runtime since let expressions are not allowed as abstract syntax expressions. 2014-09-17 21:59:45 +00:00
kr.angelov
621d748bac a major revision of the bytecode generator and JIT compiler. the effect is that now we can compute with lambda functions and with true tail recursion 2014-09-11 15:39:39 +00:00
kr.angelov
4d28c7632e the code for def rules now uses proper graph update to preserve lazyness 2014-09-05 11:53:02 +00:00
kr.angelov
86b5f78c57 full support for recursive def rules in the C runtime 2014-09-05 10:09:43 +00:00
kr.angelov
bfd414554d partial implementation for recursive def rules 2014-09-01 14:51:20 +00:00
hallgren
d84c5ef171 Experimental: parallel batch compilation of grammars
On my laptop these changes speed up the full build of the RGL and example
grammars with 'cabal build' from ~95s to ~43s and the zero build from ~18s
to ~5s.

The main change is the introduction of the module GF.CompileInParallel that
replaces GF.Compile and the function GF.Compile.ReadFiles.getAllFiles. At
present, it is activated with the new -j flag, and it is only used when
combined with --make or --batch. In addition, to get parallel computations,
you need to add GHC run-time flags, e.g., +RTS -N -A20M -RTS, to the command
line.

The Setup.hs script has been modified to pass the appropriate flags to GF
for parallel compilation when compiling the RGL and example grammars, but you
need a recent version of Cabal for this to work (probably >=1.20).

Some additonal refactoring were made during this work. A new monad is used to
avoid warnings/error messages from different modules to be intertwined when
compiling in parallel, so some functios that were hardiwred to the IO or IOE
monads have been lifted to work in arbitrary monads that are instances in
the appropriate classes.
2014-08-25 09:56:00 +00:00
hallgren
8dfaf2ef65 Command line flag -s/-q now silences all warnings
These flags now do what the say.
2014-08-22 00:30:33 +00:00
hallgren
21f429caf8 Add lifted directory operations in GF.System.Directory to eliminate the need for liftIO in various places 2014-08-20 17:47:08 +00:00
hallgren
61760e4205 GF.Compile.ReadFiles: a simpler & faster way to convert from Latin1 to UTF-8 2014-08-19 14:27:15 +00:00
hallgren
cd5193b7e1 Fix warnings in 16 modules, mostly forward compatibility warnings from GHC 7.8 2014-08-13 22:16:18 +00:00
hallgren
a06351b625 Refactoring in GF.Compile and GF.ReadFiles with an eye to parallel compilation
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.
2014-08-13 16:46:11 +00:00
kr.angelov
c30e2df228 pattern matching in def rules is now supported 2014-08-11 15:53:41 +00:00
kr.angelov
584d589041 a partial support for def rules in the C runtime
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.
2014-08-11 10:59:10 +00:00