moved parts of doc to deprecated/doc

author: aarne <aarne@chalmers.se> 2010-12-22 14:08:42 +0000
committer: aarne <aarne@chalmers.se> 2010-12-22 14:08:42 +0000
commit: ce15ec7b787479ca4c7295863ea7fa5cfdd16755 (patch)
tree: f47d9227ab535781d44d00e6232b8c62902167df /doc/gf-formalism.html
parent: fb722fe8e2cedee3b42d7fb0c9da61ace74f3e22 (diff)
1 files changed, 0 insertions, 350 deletions
diff --git a/doc/gf-formalism.html b/doc/gf-formalism.html
deleted file mode 100644
index 52d9256aa..000000000
--- a/doc/gf-formalism.html
+++ /dev/null
@@ -1,350 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
-<HTML>
-<HEAD>
-<META NAME="generator" CONTENT="http://txt2tags.sf.net">
-<TITLE>A Birds-Eye View of GF as a Grammar Formalism</TITLE>
-</HEAD><BODY BGCOLOR="white" TEXT="black">
-<P ALIGN="center"><CENTER><H1>A Birds-Eye View of GF as a Grammar Formalism</H1>
-<FONT SIZE="4">
-<I>Author: Aarne Ranta</I><BR>
-Last update: Thu Feb  2 14:16:01 2006
-</FONT></CENTER>
-
-<P></P>
-<HR NOSHADE SIZE=1>
-<P></P>
-    <UL>
-    <LI><A HREF="#toc1">GF in a few words</A>
-    <LI><A HREF="#toc2">History of GF</A>
-    <LI><A HREF="#toc3">Some key ingredients of GF in other grammar formalisms</A>
-    <LI><A HREF="#toc4">Examples of descriptions in each formalism</A>
-    <LI><A HREF="#toc5">Lambda terms and records</A>
-    <LI><A HREF="#toc6">The structure of GF formalisms</A>
-    <LI><A HREF="#toc7">The expressivity of GF</A>
-    <LI><A HREF="#toc8">Grammars and parsing</A>
-    <LI><A HREF="#toc9">Grammars as software libraries</A>
-    <LI><A HREF="#toc10">Multilinguality</A>
-    <LI><A HREF="#toc11">Parametrized modules</A>
-    </UL>
-
-<P></P>
-<HR NOSHADE SIZE=1>
-<P></P>
-<P>
-<IMG ALIGN="middle" SRC="Logos/gf0.png" BORDER="0" ALT="">
-</P>
-<P>
-<I>Abstract. This document gives a general description of the</I>
-<I>Grammatical Framework (GF), with comparisons to other grammar</I>
-<I>formalisms such as CG, ACG, HPSG, and LFG.</I>
-</P>
-<P>
-<!-- NEW -->
-</P>
-<A NAME="toc1"></A>
-<H2>GF in a few words</H2>
-<P>
-Grammatical Framework (GF) is a grammar formalism 
-based on <B>constructive type theory</B>.
-</P>
-<P>
-GF makes a distinction between <B>abstract syntax</B> and <B>concrete syntax</B>.
-</P>
-<P>
-The abstract syntax part of GF is a <B>logical framework</B>, with
-dependent types and higher-order functions.
-</P>
-<P>
-The concrete syntax is a system of <B>records</B> containing strings and features.
-</P>
-<P>
-A GF grammar defines a <B>reversible homomorphism</B> from an abstract syntax to a
-concrete syntax.
-</P>
-<P>
-A <B>multilingual GF grammar</B> is a set of concrete syntaxes associated with
-one abstract syntax.
-</P>
-<P>
-GF grammars are written in a high-level <B>functional programming language</B>,
-which is compiled into a <B>core language</B> (GFC).
-</P>
-<P>
-GF grammars can be used as <B>resources</B>, i.e. as libraries for writing
-new grammars; these are compiled and optimized by the method of
-<B>grammar composition</B>.
-</P>
-<P>
-GF has a <B>module system</B> that supports grammar engineering and separate 
-compilation.
-</P>
-<P>
-<!-- NEW -->
-</P>
-<A NAME="toc2"></A>
-<H2>History of GF</H2>
-<P>
-1988. Intuitionistic Categorial Grammar; type theory as abstract syntax,
-playing the role of Montague's analysis trees. Grammars implemented in Prolog.
-</P>
-<P>
-1994. Type-Theoretical Grammar. Abstract syntax organized as a system of
-combinators. Grammars implemented in ALF.
-</P>
-<P>
-1996. Multilingual Type-Theoretical Grammar. Rules for generating six
-languages from the same abstract syntax. Grammars implemented in ALF, ML, and
-Haskell.
-</P>
-<P>
-1998. The first implementation of GF as a language of its own.
-</P>
-<P>
-2000. New version of GF: high-level functional source language, records used
-for concrete syntax.
-</P>
-<P>
-2003. The module system.
-</P>
-<P>
-2004. Ljunglöf's thesis <I>Expressivity and Complexity of GF</I>.
-</P>
-<P>
-<!-- NEW -->
-</P>
-<A NAME="toc3"></A>
-<H2>Some key ingredients of GF in other grammar formalisms</H2>
-<UL>
-<LI>[GF ]: Grammatical Framework
-<LI>[CG ]: categorial grammar
-<LI>[ACG ]: abstract categorial grammar
-<LI>[HPSG ]: head-driven phrase structure grammar
-<LI>[LFG ]: lexical functional grammar
-</UL>
-
-<TABLE CELLPADDING="4" BORDER="1">
-<TR>
-<TD ALIGN="center">/</TD>
-<TD>GF</TD>
-<TD>ACG</TD>
-<TD>LFG</TD>
-<TD>HPSG</TD>
-<TD>CG</TD>
-</TR>
-<TR>
-<TD>abstract vs concrete syntax</TD>
-<TD>X</TD>
-<TD>X</TD>
-<TD>?</TD>
-<TD>-</TD>
-<TD>-</TD>
-</TR>
-<TR>
-<TD>type theory</TD>
-<TD>X</TD>
-<TD>X</TD>
-<TD>-</TD>
-<TD>-</TD>
-<TD>X</TD>
-</TR>
-<TR>
-<TD>records and features</TD>
-<TD>X</TD>
-<TD>-</TD>
-<TD>X</TD>
-<TD>X</TD>
-<TD>-</TD>
-</TR>
-</TABLE>
-
-<P></P>
-<P>
-<!-- NEW -->
-</P>
-<A NAME="toc4"></A>
-<H2>Examples of descriptions in each formalism</H2>
-<P>
-To be written...
-</P>
-<P>
-<!-- NEW -->
-</P>
-<A NAME="toc5"></A>
-<H2>Lambda terms and records</H2>
-<P>
-In CS, abstract syntax is trees and concrete syntax is strings.
-This works more or less for programming languages.
-</P>
-<P>
-In CG, all syntax is lambda terms. 
-</P>
-<P>
-In Montague grammar, abstract syntax is lambda terms and
-concrete syntax is trees. Abstract syntax as lambda terms
-can be considered well-established.
-</P>
-<P>
-In PATR and HPSG, concrete syntax it records. This can be considered
-well-established for natural languages.
-</P>
-<P>
-In ACG, both are lambda terms. This is more general than GF,
-but reversibility requires linearity restriction, which can be
-unnatural for grammar writing.
-</P>
-<P>
-In GF, linearization from lambda terms to records is reversible,
-and grammar writing is not restricted to linear terms.
-</P>
-<P>
-Grammar composition in ACG is just function composition. In GF,
-it is more restricted...
-</P>
-<P>
-<!-- NEW -->
-</P>
-<A NAME="toc6"></A>
-<H2>The structure of GF formalisms</H2>
-<P>
-The following diagram (to be drawn properly!) describes the
-levels.
-</P>
-<PRE>
-         |   programming language design
-         V
-    GF source language
-         |
-         |   type-directed partial evaluation
-         V
-    GFC assembly language
-         |
-         |   Ljunglöf's translation
-         V
-    MCFG parser
-</PRE>
-<P>
-The last two phases are nontrivial mathematica properties.
-</P>
-<P>
-In most grammar formalisms, grammarians have to work on the GFC
-(or MCFG) level.
-</P>
-<P>
-Maybe they use macros - they are therefore like macro assemblers. But there
-are no separately compiled library modules, no type checking, etc.
-</P>
-<P>
-<!-- NEW -->
-</P>
-<A NAME="toc7"></A>
-<H2>The expressivity of GF</H2>
-<P>
-Parsing complexity is the same as MCFG: polynomial, with
-unrestricted exponent depending on grammar.
-This is between TAG and HPSG.
-</P>
-<P>
-If semantic well-formedness (type theory) is taken into account,
-then arbitrary logic can be expressed. The well-formedness of
-abstract syntax is decidable, but the well-formedness of a
-concrete-syntax string can require an arbitrary proof construction
-and is therefore undecidable.
-</P>
-<P>
-Separability between AS and CS: like TAG (Tree Adjoining Grammar), GF
-has the goal of assigning intended trees for strings. This is
-generalized to shared trees for different languages.
-</P>
-<P>
-The high-level language strives after the properties of
-writability and readability (programming language notions).
-</P>
-<P>
-<!-- NEW -->
-</P>
-<A NAME="toc8"></A>
-<H2>Grammars and parsing</H2>
-<P>
-In many projects, a grammar is just seen as a <B>declarative parsing program</B>.
-</P>
-<P>
-For GF, a grammar is primarily the <B>definition of a language</B>.
-</P>
-<P>
-Detaching grammars from parsers is a good idea, giving
-</P>
-<UL>
-<LI>more efficient and robust parsing (statistical etc)
-<LI>cleaner grammars
-</UL>
-
-<P>
-Separating abstract from concrete syntax is a prerequisite for this:
-we want parsers to return abstract syntax objects, and these must exist
-independently of parse trees.
-</P>
-<P>
-A possible radical approach to parsing: 
-use a grammar to generate a treebank and machine-learn
-a statistical parser from this.
-</P>
-<P>
-Comparison: Steedman in CCG has done something like this.
-</P>
-<P>
-<!-- NEW -->
-</P>
-<A NAME="toc9"></A>
-<H2>Grammars as software libraries</H2>
-<P>
-Reuse for different purposes.
-</P>
-<P>
-Grammar composition.
-</P>
-<P>
-<!-- NEW -->
-</P>
-<A NAME="toc10"></A>
-<H2>Multilinguality</H2>
-<P>
-In <B>application grammars</B>, the AS is a semantic
-model, and a CS covers domain terminology and idioms.
-</P>
-<P>
-This can give publication-quality translation on
-limited domains (e.g. the WebALT project).
-</P>
-<P>
-Resource grammars with grammar composition lead to
-<B>compile-time transfer</B>.
-</P>
-<P>
-When is <B>run-time transfer</B> necessary?
-</P>
-<P>
-Cf. CLE (Core Language Engine).
-</P>
-<P>
-<!-- NEW -->
-</P>
-<A NAME="toc11"></A>
-<H2>Parametrized modules</H2>
-<P>
-This notion comes from the ML language in the 1980's.
-</P>
-<P>
-It can be used for sharing even more code between languages
-than their AS.
-</P>
-<P>
-Especially, for related languages (Scandinavian, Romance).
-</P>
-<P>
-Cf. grammar porting in CLE: what they do with untyped 
-macro packages GF does with typable interfaces.
-</P>
-
-<!-- html code generated by txt2tags 2.0 (http://txt2tags.sf.net) -->
-<!-- cmdline: txt2tags -thtml -\-toc gf-formalism.txt -->
-</BODY></HTML>
author	aarne <aarne@chalmers.se>	2010-12-22 14:08:42 +0000
committer	aarne <aarne@chalmers.se>	2010-12-22 14:08:42 +0000
commit	ce15ec7b787479ca4c7295863ea7fa5cfdd16755 (patch)
tree	f47d9227ab535781d44d00e6232b8c62902167df /doc/gf-formalism.html
parent	fb722fe8e2cedee3b42d7fb0c9da61ace74f3e22 (diff)