summaryrefslogtreecommitdiff
path: root/src/compiler/GF/Command/Abstract.hs
AgeCommit message (Collapse)Author
2016-04-07GF shell: fix a parsing problem with the cc commandhallgren
This patch fixes a problem introduced last year when the GF shell was refactored to allow more commands to be treated uniformly and be part of pipes. The cc command was one of those commands, but unfortunately this introduced a parsing problem, e.g. > cc "last" constant not found: last > cc "last"++"year" command not parsed: cc "last"++"year" This happened because the generic command line parser in GF.Command.{Abstract,Parse} assumes that all commands have an argument of type PGF.Expr. Commands that expect other types of arguments have to use PGF.showExpr combined with other conversion to the argument type they expect. The cc command excpets a GF.Grammar.Term, and unfortunately not all terms survice the roundtrip through PGF.Expr, in part because of an additional hack to allow strings to be roundtripped through PGF.Expr without adding superfluous double quotes. To solve the problem, this patch + makes room for arguments of type Term in the Argument type in GF.Command.Abstract. + makes a special case for the cc command in GF.Command.Parse, by calling the partial parser 'runPartial pTerm' recently added in GF.Grammar.Lexer and GF.Grammar.Parser. Care was taken so that that "|" and ";" can be used both inside terms and as separators between commands in the shell, e.g. things like the following now work: > cc ("a"|"b") | ps -lexcode variants { "a" ; "b" } + introduces a type CommandArgument that replaces [Expr] as the type of values passed between commands in pipes. It has room for values of type [Expr], [String] and Term, thus eliminating the need to roundtrip through the Expr type all the time. The hack to avoid adding superfluous quotes when strings are roundtripped through Expr has been left in place for now, but can probably be removed.
2015-08-12GF shell: source commands (cc, sd, so, ss & dg) can now be used in pipeshallgren
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.
2015-08-10Refactor GF shell modules to improve modularity and reusabilityhallgren
+ Move type CommandInfo from GF.Command.Commands to a new module GF.Commands.CommandInfo and make it independent of the PGF type. + Make the module GF.Command.Interpreter independent of the PGF type and eliminate the import of GF.Command.Commands. + Move the implementation of the "help" command to its own module GF.Command.Help
2013-11-05Eliminate mutual dependencies between the GF compiler and the PGF libraryhallgren
+ References to modules under src/compiler have been eliminated from the PGF library (under src/runtime/haskell). Only two functions had to be moved (from GF.Data.Utilities to PGF.Utilities) to make this possible, other apparent dependencies turned out to be vacuous. + In gf.cabal, the GF executable no longer directly depends on the PGF library source directory, but only on the exposed library modules. This means that there is less duplication in gf.cabal and that the 30 modules in the PGF library will no longer be compiled twice while building GF. To make this possible, additional PGF library modules have been exposed, even though they should probably be considered for internal use only. They could be collected in a PGF.Internal module, or marked as "unstable", to make this explicit. + Also, by using the -fwarn-unused-imports flag, ~220 redundant imports were found and removed, reducing the total number of imports by ~15%.
2012-03-26Workaround for bug in ghc-7.2.2hallgren
An apparent bug in ghc-7.2.2 causes the type Value to be exported from PGF.Data. Workaround: restrict the imports from PGF.Data in GF.Command.Abstract and GF.Compile.GeneratePMCFG to avoid the clash with locally defined type Value. (ghc-7.0.4 and ghc-7.4.1 appear to be free from this bug.)
2009-12-13reorganize the directories under src, and rescue the JavaScript interpreter ↵krasimir
from deprecated