GitHub/gf-core
1
0
Fork 1
mirror of https://github.com/GrammaticalFramework/gf-core.git synced 2026-05-22 09:32:53 -06:00
Code Issues Packages Projects Releases Wiki Activity

updated resource doc intro with overloaded examples

Browse Source
This commit is contained in:
aarne
2007-06-19 09:04:22 +00:00
parent 632a7d3017
commit e3a0c60e89
1 changed files with 74 additions and 63 deletions
Download Patch File Download Diff File Expand all files Collapse all files

81
doc/resource.txt
View File

@@ -25,13 +25,15 @@ Last update: %%date(%c)
#CLEARPAGE #CLEARPAGE
This document is about the This document is a guide for using the
GF Resource Grammar Library. It presupposes knowledge of GF and its GF Resource Grammar Library. It presupposes knowledge of GF and its
module system, knowledge that can be acquired e.g. from the GF module system, knowledge that can be acquired e.g. from the
tutorial. We start with an introduction to the library, and proceed to GF tutorial.
We start with an introduction to the library, and proceed to
details with the goal of covering all that one needs to know details with the goal of covering all that one needs to know
in order to use the library. in order to use the library.
How to write one's own resource grammar (i.e. to implement the API for
How to //write// one's own resource grammar (i.e. to implement the API for
a new language), is covered by a separate Resource-HOWTO document (available in a new language), is covered by a separate Resource-HOWTO document (available in
the www address below). the www address below).
@@ -39,7 +41,7 @@ The main part of the document (the API documentation) is generated
from the actual GF code by using the ``gfdoc`` tool. This documentation from the actual GF code by using the ``gfdoc`` tool. This documentation
is also available on-line in HTML format in is also available on-line in HTML format in
[``http://www.cs.chalmers.se/~aarne/GF/lib/resource-1.0/doc/`` http://www.cs.chalmers.se/~aarne/GF/lib/resource-1.0/doc/]. [``http://www.cs.chalmers.se/~aarne/GF/lib/resource-1.2/doc/`` http://www.cs.chalmers.se/~aarne/GF/lib/resource-1.2/doc/].
=Motivation= =Motivation=
@@ -55,7 +57,7 @@ is that of a skilled programmer with
a practical knowledge of the target languages, but without a practical knowledge of the target languages, but without
theoretical knowledge about their grammars. theoretical knowledge about their grammars.
Such a combination of Such a combination of
skills is typical of programmers who want to localize skills is typical of programmers who, for instance, want to localize
software to new languages. software to new languages.
The current resource languages are The current resource languages are
@@ -77,8 +79,11 @@ The first three letters (``Eng`` etc) are used in grammar module names.
The Arabic and Catalan implementations are still incomplete, but The Arabic and Catalan implementations are still incomplete, but
enough to be used in many applications. enough to be used in many applications.
To give an example application, consider
music playing devices. In the application, ==An example application==
To give an example application, consider a system for steering
music playing devices by voice commands. In the application,
we may have a semantical category ``Kind``, examples we may have a semantical category ``Kind``, examples
of ``Kind``s being ``Song`` and ``Artist``. In German, for instance, ``Song`` of ``Kind``s being ``Song`` and ``Artist``. In German, for instance, ``Song``
is linearized into the noun "Lied", but knowing this is not is linearized into the noun "Lied", but knowing this is not
@@ -102,13 +107,13 @@ number, and case, and also depend on what determiner is used
("ein amerikanisches Lied" vs. "das amerikanische Lied"). All this ("ein amerikanisches Lied" vs. "das amerikanische Lied"). All this
variation is taken care of by the resource grammar function variation is taken care of by the resource grammar function
``` ```
fun AdjCN : AP -> CN -> CN mkCN : AP -> CN -> CN
``` ```
(see the tables in the end of this document for the list of all resource grammar (see the table in the end of this document for the list of all resource grammar
functions). The resource grammar implementation of the rule adding properties functions). The resource grammar implementation of the rule adding properties
to kinds is to kinds is
``` ```
lin PropKind kind prop = AdjCN prop kind lin PropKind kind prop = mkCN prop kind
``` ```
given that given that
``` ```
@@ -127,7 +132,7 @@ pick a different linearization of ``Song``,
lin Song = mkN "chanson" feminine lin Song = mkN "chanson" feminine
``` ```
But to linearize ``PropKind``, we can use the very same rule as in German. But to linearize ``PropKind``, we can use the very same rule as in German.
The resource function ``AdjCN`` has different implementations in the two The resource function ``mkCN`` has different implementations in the two
languages (e.g. a different word order in French), languages (e.g. a different word order in French),
but the application programmer need not care about the difference. but the application programmer need not care about the difference.
@@ -156,6 +161,7 @@ here is the complete implementation of a small system with songs and properties.
The abstract syntax defines a "domain ontology": The abstract syntax defines a "domain ontology":
``` ```
abstract Music = { abstract Music = {
cat cat
Kind, Kind,
Property ; Property ;
@@ -167,22 +173,24 @@ The abstract syntax defines a "domain ontology":
``` ```
The concrete syntax is defined by a functor (parametrized module), The concrete syntax is defined by a functor (parametrized module),
independently of language, by opening independently of language, by opening
two interfaces: the resource ``Grammar`` and an application lexicon. two interfaces: the resource ``Syntax`` and an application lexicon.
``` ```
incomplete concrete MusicI of Music = open Grammar, MusicLex in { incomplete concrete MusicI of Music = open Syntax, MusicLex in {
lincat lincat
Kind = CN ; Kind = CN ;
Property = AP ; Property = AP ;
lin lin
PropKind k p = AdjCN p k ; PropKind k p = mkCN p k ;
Song = UseN song_N ; Song = mkCN song_N ;
American = PositA american_A ; American = mkAP american_A ;
} }
``` ```
The application lexicon ``MusicLex`` has an abstract syntax that extends The application lexicon ``MusicLex`` has an abstract syntax that extends
the resource category system ``Cat``. the resource category system ``Cat``.
``` ```
abstract MusicLex = Cat ** { abstract MusicLex = Cat ** {
fun fun
song_N : N ; song_N : N ;
american_A : A ; american_A : A ;
@@ -194,26 +202,26 @@ inflectional paradigms module for that language:
concrete MusicLexGer of MusicLex = concrete MusicLexGer of MusicLex =
CatGer ** open ParadigmsGer in { CatGer ** open ParadigmsGer in {
lin lin
song_N = reg2N "Lied" "Lieder" neuter ; song_N = mkN "Lied" "Lieder" neuter ;
american_A = regA "amerikanisch" ; american_A = mkA "amerikanisch" ;
} }
concrete MusicLexFre of MusicLex = concrete MusicLexFre of MusicLex =
CatFre ** open ParadigmsFre in { CatFre ** open ParadigmsFre in {
lin lin
song_N = regGenN "chanson" feminine ; song_N = mkN "chanson" feminine ;
american_A = regA "américain" ; american_A = mkA "américain" ;
} }
``` ```
The top-level ``Music`` grammars are obtained by The top-level ``Music`` grammars are obtained by
instantiating the two interfaces of ``MusicI``: instantiating the two interfaces of ``MusicI``:
``` ```
concrete MusicGer of Music = MusicI with concrete MusicGer of Music = MusicI with
(Grammar = GrammarGer), (Syntax = SyntaxGer),
(MusicLex = MusicLexGer) ; (MusicLex = MusicLexGer) ;
concrete MusicFre of Music = MusicI with concrete MusicFre of Music = MusicI with
(Grammar = GrammarFre), (Syntax = SyntaxFre),
(MusicLex = MusicLexFre) ; (MusicLex = MusicLexFre) ;
``` ```
Both of these files can use the same ``path``, defined as Both of these files can use the same ``path``, defined as
@@ -233,12 +241,12 @@ vocabulary and inflectional paradigms. For instance, Finnish is added as follows
concrete MusicLexFin of MusicLex = concrete MusicLexFin of MusicLex =
CatFin ** open ParadigmsFin in { CatFin ** open ParadigmsFin in {
lin lin
song_N = regN "kappale" ; song_N = mkN "kappale" ;
american_A = regA "amerikkalainen" ; american_A = mkA "amerikkalainen" ;
} }
concrete MusicFin of Music = MusicI with concrete MusicFin of Music = MusicI with
(Grammar = GrammarFin), (Syntax = SyntaxFin),
(MusicLex = MusicLexFin) ; (MusicLex = MusicLexFin) ;
``` ```
More work is of course needed if the language-independent linearizations in More work is of course needed if the language-independent linearizations in
@@ -252,12 +260,12 @@ before,
concrete MusicLexEng of MusicLex = concrete MusicLexEng of MusicLex =
CatEng ** open ParadigmsEng in { CatEng ** open ParadigmsEng in {
lin lin
song_N = regN "song" ; song_N = mkN "song" ;
american_A = regA "American" ; american_A = mkA "American" ;
} }
concrete MusicEng0 of Music = MusicI with concrete MusicEng0 of Music = MusicI with
(Grammar = GrammarEng), (Syntax = SyntaxEng),
(MusicLex = MusicLexEng) ; (MusicLex = MusicLexEng) ;
``` ```
The module ``MusicEng0`` would not be used on the top level, however, but The module ``MusicEng0`` would not be used on the top level, however, but
@@ -266,17 +274,20 @@ another module would be built on top of it, with a restricted import from
except ``PropKind``, and except ``PropKind``, and
gives its own definition of this function: gives its own definition of this function:
``` ```
concrete MusicEng of Music = concrete MusicEng of Music = MusicEng0 - [PropKind] **
MusicEng0 - [PropKind] ** open GrammarEng in { open SyntaxEng in {
lin lin
PropKind k p = PropKind k p = mkCN k (mkRS (mkRCl which_RP (mkVP p))) ;
RelCN k (UseRCl TPres ASimul PPos
(RelVP IdRP (UseComp (CompAP p)))) ;
} }
``` ```
==Lock fields== ==Lock fields==
//This section is only relevant as a guide to error messages that have to do with lock fields, and can be skipped otherwise.//
FIXME: this section may become obsolete.
When the categories of the resource grammar are used When the categories of the resource grammar are used
in applications, a **lock field** is added to their linearization types. in applications, a **lock field** is added to their linearization types.
The lock field for a category ``C`` is a record field The lock field for a category ``C`` is a record field
@@ -419,7 +430,7 @@ Below this top-level module exposing overloaded constructors,
there are around 10 abstract modules, each defining constructors for there are around 10 abstract modules, each defining constructors for
a group of one or more related categories. For instance, the module a group of one or more related categories. For instance, the module
``Noun`` defines how to construct common nouns, noun phrases, and determiners. ``Noun`` defines how to construct common nouns, noun phrases, and determiners.
But these special modules are seldom needed by the users of the library. But these special modules are seldom or never needed by the users of the library.
TODO: when are they needed? TODO: when are they needed?