Commit Graph

15 Commits

Author SHA1 Message Date
hallgren
f62edb3e1e Comment out some dead code found with -fwarn-unused-binds
Also fixed some warnings and tightened some imports
2015-08-28 13:59:43 +00:00
krasimir
3d502a76b3 added all orthographic primitives 2015-05-11 13:01:39 +00:00
hallgren
3aaeaf1325 Translating linearization functions to Haskell: move Haskell AST and pretty printer to GF.Haskell
For further separation of pretty printing concerns from conversion concerns,
the Haskell AST and pretty printer has been moved to its own module,
GF.Haskell, also allowing it to be reused in other places where Haskell
code is generated.
2015-04-14 12:44:14 +00:00
hallgren
e2e943eabc GF.Compile.ConcreteToHaskell: some documentation 2015-04-07 14:51:52 +00:00
krasimir
3ee931f905 added option -plus-as-bind which treats (+) as a bind when used with runtime variables 2015-02-20 13:26:12 +00:00
hallgren
43a873b53f 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
686f570660 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
ad8b6429ec 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
240ba80209 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
0b114195aa 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
4348ae40d2 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
6db2845375 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
51a233b2f1 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
1f60646f41 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
dc3fd2c044 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