From b974c099511a90d41dd234e3bbeccdcc57b38606 Mon Sep 17 00:00:00 2001 From: "John J. Camilleri" Date: Wed, 5 Dec 2018 15:48:07 +0100 Subject: [PATCH] Update runtime-api.html to match the new visual look of the GF website --- doc/runtime-api.html | 110 ++++++++++++++++++++++++------------------- 1 file changed, 61 insertions(+), 49 deletions(-) diff --git a/doc/runtime-api.html b/doc/runtime-api.html index 4ed05c3d3..2bc74c409 100644 --- a/doc/runtime-api.html +++ b/doc/runtime-api.html @@ -1,29 +1,26 @@ - + + + C Runtime API + + + - - -

Using the Python Haskell Java C# binding to the C runtime

- - Choose a language: Haskell Python Java C# - +
+
+ + GF Logo + +

+ Using the + Python + Haskell + Java + C# + binding to the C runtime +

+

Krasimir Angelov, July 2015 - August 2017

+ Choose a language: + Haskell + Python + Java + C# +
+
-

Krasimir Angelov, July 2015 - August 2017

-

Loading the Grammar

Before you use the Python binding you need to import the PGF2 modulepgf modulepgf packagePGFSharp package: @@ -127,7 +138,7 @@ Concr eng = gr.Languages["AppEng"];

Parsing

-All language specific services are available as +All language specific services are available as methods of the class pgf.Concrfunctions that take as an argument an object of type Concrmethods of the class Concrmethods of the class Concr. For example to invoke the parser, you can call: 
@@ -220,10 +231,10 @@ Console.WriteLine(ep.Item1);
 PhrUtt NoPConj (UttS (UseCl (TTAnt TPres ASimul) PPos (PredVP (DetNP (DetQuant this_Quant NumSg)) (UseComp (CompNP (DetCN (DetQuant IndefArt NumSg) (AdjCN (PositA small_A) (UseN theatre_N)))))))) NoVoc
-

Note that depending on the grammar it is absolutely possible that for -a single sentence you might get infinitely many trees. +

Note that depending on the grammar it is absolutely possible that for +a single sentence you might get infinitely many trees. In other cases the number of trees might be finite but still enormous. -The parser is specifically designed to be lazy, which means that +The parser is specifically designed to be lazy, which means that each tree is returned as soon as it is found before exhausting the full search space. For grammars with a patological number of trees it is advisable to pick only the top N trees @@ -246,16 +257,16 @@ parsing with a different start category can be done as follows:

-There is also the function parseWithHeuristics which -takes two more paramaters which let you to have a better control +There is also the function parseWithHeuristics which +takes two more paramaters which let you to have a better control over the parser's behaviour: 
 Prelude PGF2> let res = parseWithHeuristics eng (startCat gr) heuristic_factor callbacks
-There is also the method parseWithHeuristics which -takes two more paramaters which let you to have a better control +There is also the method parseWithHeuristics which +takes two more paramaters which let you to have a better control over the parser's behaviour: 
 Iterable<ExprProb> iterable = eng.parseWithHeuristics(gr.startCat(), heuristic_factor, callbacks);
@@ -281,7 +292,7 @@ to factor 0.0. When we increase the factor then parsing becomes faster
 but at the same time the sorting becomes imprecise. The worst
 factor is 1.0. In any case the parser always returns the same set of
 trees but in different order. Our experience is that even a factor
-of about 0.6-0.8 with the translation grammar still orders 
+of about 0.6-0.8 with the translation grammar still orders
 the most probable tree on top of the list but further down the list,
 the trees become shuffled.
 

@@ -457,7 +468,7 @@ the object has the following public final variables:
 
 

 
-The linearization works even if there are functions in the tree 
+The linearization works even if there are functions in the tree
 that doesn't have linearization definitions. In that case you
 will just see the name of the function in the generated string.
 It is sometimes helpful to be able to see whether a function
@@ -483,7 +494,7 @@ true
 
 

 An already constructed tree can be analyzed and transformed
-in the host application. For example you can deconstruct 
+in the host application. For example you can deconstruct
 a tree into a function name and a list of arguments:
 
 >>> e.unpack()
@@ -523,8 +534,8 @@ literal. For example the result from:
 
 The result from unApp is Just if the expression
 is an application and Nothing in all other cases.
-Similarly, if the tree is a literal string then the return value 
-from unStr will be Just with the actual literal. 
+Similarly, if the tree is a literal string then the return value
+from unStr will be Just with the actual literal.
 For example the result from:
 
 
@@ -534,8 +545,8 @@ Prelude PGF2> readExpr "\"literal\"" >>= unStr
 
 The result from unApp is not null if the expression
 is an application, and null in all other cases.
-Similarly, if the tree is a literal string then the return value 
-from unStr will not be null with the actual literal. 
+Similarly, if the tree is a literal string then the return value
+from unStr will not be null with the actual literal.
 For example the output from:
 
 
@@ -545,15 +556,15 @@ System.out.println(elit.unStr());
 
 The result from UnApp is not null if the expression
 is an application, and null in all other cases.
-Similarly, if the tree is a literal string then the return value 
-from UnStr will not be null with the actual literal. 
+Similarly, if the tree is a literal string then the return value
+from UnStr will not be null with the actual literal.
 For example the output from:
 
 
 Expr elit = Expr.ReadExpr("\"literal\"");
 Console.WriteLine(elit.UnStr());
 

-is just the string "literal". 
+is just the string "literal".
 Situations like this can be detected
 in Python by checking the type of the result from unpack.
 It is also possible to get an integer or a floating point number
@@ -569,7 +580,7 @@ There are also the methods UnAbs, UnInt, UnFloat and
 
 

 
-Constructing new trees is also easy. You can either use 
+Constructing new trees is also easy. You can either use
 readExpr to read trees from strings, or you can
 construct new trees from existing pieces. This is possible by
 
@@ -612,7 +623,7 @@ Console.WriteLine(e2);
 
If the host application needs to do a lot of expression manipulations,
 then it is helpful to use a higher-level API to the grammar,
 also known as "embedded grammars" in GF. The advantage is that
-you can construct and analyze expressions in a more compact way.
 
+you can construct and analyze expressions in a more compact way.

 
 
 
In Python you first have to embed the grammar by calling:
@@ -721,7 +732,7 @@ call the method default. The following is an example:
       def on_DetCN(self,quant,cn):
         print("Found DetCN")
         cn.visit(self)
-			
+
       def on_AdjCN(self,adj,cn):
         print("Found AdjCN")
         cn.visit(self)
@@ -1007,7 +1018,7 @@ Traceback (most recent call last):
 pgf.PGFError: The concrete syntax is not loaded
 

 
-Before using the concrete syntax, you need to explicitly load it: 
+Before using the concrete syntax, you need to explicitly load it:
 
 >>> eng.load("AppEng.pgf_c")
 >>> print(eng.lookupMorpho("letter"))
@@ -1060,7 +1071,7 @@ Traceback (most recent call last):
 pgf.PGFError: The concrete syntax is not loaded
 

 
-Before using the concrete syntax, you need to explicitly load it: 
+Before using the concrete syntax, you need to explicitly load it:
 
 eng.load("AppEng.pgf_c")
 for (MorphoAnalysis an : eng.lookupMorpho("letter")) {
@@ -1289,6 +1300,7 @@ graph {
 }
 

 
+
+
-