These changes are inspired by the gf -cshell implementation of these commands.
The output of the linearize command has been changed to remove superfluous
blank lines and commas, and deliver the result as a list of strings instead of
a single multi-line string. This makes it possible to use -all and pipe the
results to the parse command. This also means that with -treebank -all,
the language tag will be repeated for each result from the same language.
The parse command, when trying to parse with more than one language, would
"forget" other results after a failed parse, and thus not send all
successful parses through the pipe. For example, if English is not the first
language in the grammar,
p "hello" | l
would output nothing, instead of translations of "hello" to all languages,
forcing the user to write
p -lang=Eng "hello" | l
instead, to get the expected result. The cause of this behaviour was in the
function fromParse, which was rather messy, so I assume it is not intentional,
but the result of a programming mistake at some point.
The fromParse function has now been refactored from a big recursive function
into
fromParse opts = foldr (joinPiped . fromParse1 opts) void
where the helper functions fromParse1 deals with a single parse result and
joinPiped combines multiple parse results.
While the abstract Numeral inherits only Cat[Numeral,Digits], some of the
concrete NumeralNNN of Numeral inherited everything from CatNNN.
Normally the compiler outputs a warning message when a concrete syntax
contains superflous lincats, but apparently not when they get included
through inheritance...
This does not seem to cause problems in the Haskell run-time system, but the
C run-time system fails to load PGFs with superflous lincats.
This problems shows up when creating application grammars that inherit Numeral.
The Phrasebook is an example of such a grammar.
Even though the -lang flag was handled in the implementation, it was not
documented, and GF.Command.Interpreter rejects undocumented flags:
option not interpreted: lang
This must be a fairly old bug, so it suggests that the vp command isn't used
much...
pg supports only the -funs, -cats and -langs output modes.
ai IDENTIFIER shows info about a category or a function. ai can not type check
and refine metavariables in expressions.
showType :: Type -> String
categories :: PGF -> [Cat]
But both are implemented as quick hacks: categories is implemented by listing
all functions and taking the target categories from their types. showType uses
ppType copied & modified from PGF.Type, and needs a ppExpr, which is currently
implemented by wrapping showExpr...
TODO: need something correpsonding to PGF.categoryContext.
Options -all and -list use PGF2.linearizeAll, which lists all variants, but
not all forms...
Also, there is no attempt to be compatible with the output from the Haskell
run-rime shell, which produces superfluous blank lines (-all) or
commas (-list), and mixes tagged and untagged lines (-treebank -all).
The print_history command was among the commands implemented in an ad-hoc
way instead of being handled by the command line interpreter, which means
it could not be used in a pipe, as in the example in the help info.
The refactoring in the previous patch made this old bug easy to fix.
Also fixed a bug in the "empty" command, introduced when moving the PGF from
CommandEnv to GFEnv.
TODO: fix the undocumented eh command. A comment in the help info for
print_history, and some commented out old code, suggest that eh means
"execute_history", but at present it does nothing...
+ Generalize the CommandInfo type by parameterizing it on the monad
instead of just the environment.
+ Generalize the commands defined in
GF.Command.{Commands,Commands2,CommonCommands,SourceCommands,HelpCommand}
to work in any monad that supports the needed operations.
+ Liberate GF.Command.Interpreter from the IO monad.
Also, move the current PGF from CommandEnv to GFEnv in
GF.Interactive, making the command interpreter even more generic.
+ Use a state monad to maintain the state of the interpreter in
GF.{Interactive,Interactive2}.
These commands are now implemented as regular commands (i.e. using the
CommandInfo data type) in the new module GF.Command.SourceCommands.
The list of commands exported from GF.Command.Commmands now called pgfCommands
instead of allCommands.
The list allCommands of all commands is now assembled
from sourceCommands, pgfCommands, commonCommands and helpCommand in
GF.Interactive.
