a Graphical User Environment for Natural Language ... - CiteSeerX

0 downloads 0 Views 395KB Size Report
At the top of the widget we nd a row of menu buttons (the MenuBar). ...... that the string and logical form are also available (if instantiated) in the .... Max is 10000 + (L * L * 300). ..... rather they are introduced by the predicate boolean type/2.
HDRUG: a Graphical User Environment for Natural Language Processing in Prolog Gertjan van Noord Alfa-informatica and BCN University of Groningen

Preface Hdrug is a system that evolved over the years. It simply started out as my personal way of doing NLP in Prolog. Because of changes in interests, available software, etc, the design of the system became more and more modular and exible. Furthermore, the availability of ProTcl also made the system really `pretty' in comparison with Sicstus' built-in GM library. The name of the system historically is an acronym for `head-driven uni cation grammar'. However, given that Hdrug now is a shell rather than a particular NLP system, the name should not be regarded as an acronym anymore. Rather, it re ects some people's feelings about my addiction to this : : : . If you have any questions or remarks don't hesitate to contact me at [email protected]. I hope some people nd this system useful. Gertjan van Noord, September 1994.

1

Contents 1 Introduction

4

1.1 An Example Session of Hdrug : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 4 1.2 What example grammars/parsers/generators are provided? : : : : : : : : : : : : : 9 1.3 Comparison : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 12

2 Using the Hdrug Graphical User Interface 2.1 Using the Mouse : : : : : 2.1.1 The MenuBar : : : 2.1.2 The ObjectBar : : 2.1.3 The ButtonBar : : 2.2 The Command-interpreter

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

3.1 General Setup : : : : : : : : : : : : : : : : : : : : : : : 3.1.1 Files : : : : : : : : : : : : : : : : : : : : : : : : 3.2 Parsers and Generators : : : : : : : : : : : : : : : : : 3.2.1 Declaration of parsers and generators : : : : : 3.2.2 Predicates provided by a parser and generator 3.3 Top categories : : : : : : : : : : : : : : : : : : : : : : 3.4 Strings and Semantics : : : : : : : : : : : : : : : : : : 3.5 Grammar compilation : : : : : : : : : : : : : : : : : : 3.6 The Test-suite : : : : : : : : : : : : : : : : : : : : : : 3.7 Extending the Graphical User Interface : : : : : : : : 3.8 Extending the Command Interpreter : : : : : : : : : : 3.9 Viewing Prolog De nitions : : : : : : : : : : : : : : :

: : : : : : : : : : : :

: : : : : : : : : : : :

: : : : : : : : : : : :

: : : : : : : : : : : :

: : : : : : : : : : : :

: : : : : : : : : : : :

: : : : : : : : : : : :

: : : : : : : : : : : :

: : : : : : : : : : : :

: : : : : : : : : : : :

: : : : : : : : : : : :

: : : : : : : : : : : :

: : : : : : : : : : : :

: : : : : : : : : : : :

: : : : : : : : : : : :

: : : : : : : : : : : :

Term Expansion : : : : : : : : : : : : : : : : : : : : : : : : : Link Clauses : : : : : : : : : : : : : : : : : : : : : : : : : : : Flags : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Trees : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : The feature library : : : : : : : : : : : : : : : : : : : : : : : : 4.5.1 Types : : : : : : : : : : : : : : : : : : : : : : : : : : : 4.5.2 Equational constraints : : : : : : : : : : : : : : : : : : 4.5.3 Viewing Prolog Terms representing Feature Structures 4.5.4 Lists : : : : : : : : : : : : : : : : : : : : : : : : : : : : 4.5.5 Extensionality : : : : : : : : : : : : : : : : : : : : : : 4.5.6 Unify except : : : : : : : : : : : : : : : : : : : : : : : 4.5.7 Find type : : : : : : : : : : : : : : : : : : : : : : : : : 4.5.8 Term expansion : : : : : : : : : : : : : : : : : : : : : : 4.5.9 Disjunction and Negation over Atomic Values : : : : : 4.6 The lex string library : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : :

: : : : : : : : : : : : : : :

: : : : : : : : : : : : : : :

: : : : : : : : : : : : : : :

: : : : : : : : : : : : : : :

: : : : : : : : : : : : : : :

: : : : : : : : : : : : : : :

: : : : : : : : : : : : : : :

: : : : : : : : : : : : : : :

: : : : : : : : : : : : : : :

: : : : : : : : : : : : : : :

: : : : : : : : : : : : : : :

3 De ning an Application in Hdrug

4 The Hdrug Library 4.1 4.2 4.3 4.4 4.5

2

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

13 13 14 16 17 17

20 20 20 21 21 21 22 23 23 23 24 24 25

26 26 27 27 28 30 30 32 32 33 33 33 34 34 35 35

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

5.1 Where to get it? : : : : : : : : : : : : : : : : : : : : 5.2 What other software do you need? : : : : : : : : : : 5.3 How to install? : : : : : : : : : : : : : : : : : : : : : 5.3.1 Make le.defs : : : : : : : : : : : : : : : : : : 5.3.2 Installing Hdrug and the Hdrug applications

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

4.7 4.8 4.9 4.10

Extended Tk Env : : : : : Atom length : Concat : : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

5 Installation

A Useful addresses

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

36 37 37 37

38 38 38 39 39 39

42

3

Chapter 1

Introduction Hdrug is an environment to develop logic grammars / parsers / generators for natural languages. The package is written in Sicstus Prolog and Tcl/Tk. It uses ProTcl as an interface between Sicstus Prolog and Tcl/Tk. Tcl/Tk is a powerful script language to develop applications for the X-windows environment. Furthermore, LATEX output is supported too. The package comes with a number of example grammars, including a Categorial Grammar, a Tree Adjoining Grammar, a Uni cation Grammar in the spirit of Head-driven Phrase Structure Grammar, an Extraposition Grammar and a De nite Clause Grammar. The new release also contains a port of the HPSG grammar of the ALE 2.0 distribution. Each of the grammars comes with a set of parsers, such as Earley-like chart parsers, left-corner parsers and head-driven parsers. Some grammars come with variants of the head-driven generator. Hdrug allows for easy comparison of di erent parsers/generators; it has extensive possibilities to compile feature equations into Prolog terms; it can produce graphical (via Tcl/TK), LATEX and ordinary Prolog output of trees, feature structures, Prolog terms (and combinations thereof), plotted graphs of statistical information, and LATEX tables of statistical information. Etc. Etc. Using menu's, buttons (or the keyboard if you prefer) it is possible to parse sentences, generate sentences from logical form representations, view the parse trees that are derived by the parser or generator, change a particular version of the parser on the y, compare the results of parsing the same sentence(s) with a set of di erent parsers, etc. It should not be dicult to adapt an existing NLP system written in Sicstus to Hdrug. The interface between Hdrug and an application is de ned in chapter 3.

1.1 An Example Session of Hdrug

This section describes an example session of one of the applications that comes with the standard Hdrug distribution, called TL. TL is a small experimental parsing/generation system for Dutch. Some of the underlying motivations for this system are described in [14]. This application is started by the UNIX shell command TL. After a short delay this results in the appearance of the Hdrug widget. The Hdrug widget for TL is presented in gure 1.1. At the top of the widget we nd a row of menu buttons (the MenuBar). Below the row of buttons two large sub-widgets (the Canvases) are placed. At the bottom we nd a few buttons and a few labels (the ButtonBar). The labels indicate the current parser, generator and top-category. ?  debug A simple command can be executed by selecting from the MenuBar the item  followed  ? by statistics . (Luckily, most menu's will give rise to more interesting actions.) Typically, a NLP system is tested by feeding it example sentences. Let's suppose we want to parse the sentence `jan kust marie' (i.e. the Dutch equivalent of John kisses Mary). We select ? ?  parse parse sentence . This gives rise to a new window (cf. gure 1.2) in which we can either    select a sentence from a list of given sentences, or we can type in a new sentence. In this case we type in the new sentence `jan kust marie'. 4

Figure 1.1: Initial.gif

Figure 1.2: Dialog widget to select or type a test sentence

5

In the Sicstus widget some information concerning the parse process is displayed, such as the current value of the parser, the cputime it takes to parse, and two abbrevations of the? semantic  ? representations of the parse-results. Furthermore, two new buttons labelled 1 and 2 are placed on a row below the MenuBar. We will refer to this row as the ObjectBar. These two buttons refer to the two results of the parse command. Pressing a button from the ObjectBar gives rise ?to a submenu, indicating some actions we can undertake with the object. For example, selecting 1 view ?tk ?tree d ?gives rise to the parse tree of the object. This parse-tree is placed on the left canvas (cf. gure 1.3).

Figure 1.3: An Hdrug parse-tree Note that the nodes of the parse-trees are buttons. Pressing one of the nodes of the parse-trees gives rise to a display of the corresponding feature-structure in the right canvas. Alternatively, if ? we have enabled the Use New Canvas button at the bottom of the screen, then such featurestructures will appear in a new separate window. If we press the button dominating kust, we obtain the window as shown in gure 1.4. Pressing the left mouse button on an attribute name hides the corresponding value. Pressing the right mouse button on an attribute name brings the corresponding value back on the screen.

Figure 1.4: An Hdrug feature-structure  ?

Alternatively, we can select 2 view ?tk ? tree q ?. This also results in a tree to be printed on the canvas, but this time the tree represents the semantic structure of the second parse result. 6

Playing around with the other view possibilities will give you some idea of some of the possibilities of Hdrug. For example, feature structures, trees and Prolog terms can also be output via LATEX in an Xdvi window. And, of course, you can also get the output to appear in the Sicstus widget, as you ordinarily would.  ? and feature structures can also be combined. If we ask for 2 view ?tk ?  The viewing of trees ? tree matrix(syn) then we obtain the most spectacular form of output, cf. gure 1.5. Picture not included. Figure 1.5: An Hdrug feature-structure tree The current application, TL, not only can be used for parsing, but also has a built-in generation component. Selecting generate ?generate lf ?gives rise to a dialog window in which you can either type a logical form, or select one from the existing set of logical forms. Selecting, for example, the logical form kust(marie,jan), gives rise to two generation results. Again, these results are available for inspection thru the ObjectBar. The test-suite ? menu contains a number of commands that are useful if we are inter-? ested in a comparison of the behavior of a set of di erent parsers. If we select test-suite  ?  parser selection then we can indicate which parsers we want to compare. Initially all ex  isting parsers are `active'. Suppose that we want to compare only two of the parsers, namely shift reduce and right chart. We can achieve this by de-activating each of the other parsers one at the time. 1  We can now select test-suite ?compare parsers ?. Suppose we want to compare the parsers on the sentence `de man die slaapt slaapt' (the man who sleeps sleeps). This gives rise to all kinds of behavior in the Sicstus widget. In e ect Hdrug parses the sentence twice, using each of the active parsers (the shift reduce parser and the rcp3 dtrs parser). For this sentence the latter parser is fteen times faster. Before we want to conclude that this result indicates that indeed the latter parser is faster, we might want to have some more results. In fact, we could decide to parse allof our sen-? tences, and compare the results of this test-suite. This can be achieved by selecting test-suite   ? run test-suite . Time for co ee. After some time (depending on the nancial situation of your employer) your patience is rewarded and Hdrug has nished this laborious task. We can now obtain some statistical information.   ? For example, we can select the option test-suite ?view test results ?totals per #words tk . This produces the window given here in gure 1.6 (in fact this example was produced with the TG application; for the TL application something similar could be obtained). Once a parser has reached the time-out for a sentence of length n, then Hdrug refuses to use this parser for sentences longer than n. 2 It is now somewhat more interesting to get the LATEX output, as this is organized in? a di erent way. If we select test-suite ?view test results ?totals per #words latex , then we obtain the table in gure 1.7: 3 Let us now take a look at the view ?menu. This provides a number of possibilities to view objects, types and (Prolog) predicates, as de ned in the grammar les. For example, let's assume we select the option view ?predicate ?latex ?text ?. We are prompted for a predicate name. Let's choose wdel/3. After a short delay the Xdvi window now should look as follows: wdel(A; [AjB]; B): 1 Note that if you select test-suite ?using the middle mouse button, then the menu will stick and the selection

of parsers is easier. Press the same menu with the left mouse button afterwards to get rid of the sticking menu. 2 This behaviour can be altered with the useful try check ag. 3 don't take these gures literally; they have been created with an old grammar on a di erent machine :: :

7

Figure 1.6: Result of parsing the test-suite for a number of di erent parsers.

n # lc ch hc ch hc mmp hc mp 2 1 100=100 229 220 150 3 1 100=165 199 150 93 4 1 100=830 43 42 30 5 2 100=541 142 88 73 6 3 100=2420 68 48 41 7 2 100=8490 17 16 12 8 2 100=8400 18 17 11 9 3 100=4690 45 27 26 12 4 100=16560 29 27 28 15 2 100=7380 94 61 39 18 29 100=24194 70 32 61 21 8 100=17994 79 59 41 Figure 1.7: This is an example of LATEX output of a comparison of a number of di erent parsers on a a set of example sentences. The rst column indicates the length of the sentences, the second column gives the (avarage) number of readings, the third column gives the timings for the rst parser, the other columns give the relative timings for the other parsers. In this case the hc mp parser seems the most ecient one. Tables can be produced for a comparison of arbitrary numbers of parsers.

8

wdel(A; [DjB]; [DjC]):wdel(A; B; C): Note that you might have to click in the Xdvi window, to update the view in the window. If you happened to quit the Xdvi application before, you can restart it using the Prolog predicate xdvi/0. As another example, let usnow take a look at a tree oriented output thru LATEX. 4 For this ? ? ? ? purpose, we select the option view object latex tree d . We are prompted for the object number. If we select object 2, then the Xdvi window will present the following: vp np jan

   

aaa aa

vp+[np]

" bb "" b

(vp+[np])#[nnp] kust

nnp

marie

As a nal example we want to get a tree in LATEX format, of which the nodes are feature structures themselves. In order to do this, we have to select the view ?object ?latex ?tree matrix e ? option. This produces the output in gure 1.8.5 Applications typically extend the options available thru the ?di erent menus. For example, the ?  ? TL application contains the option view lexical hierarchy tk which presents the lexicon as a tree, indicating some of the structure of the hierarchical lexicon. This huge tree is placed on the canvas (cf. gure 1.9). Note that you can use the middle mouse button to scroll the canvas more conveniently. Also note that you can adapt the size of the canvas by dragging (with the left mouse button) the border of the two canvases. It is?also possible to inspect the de nition(s) of a lexical entry. Selecting view ?lexical entry ?   ? latex matrix produces a dialog box asking for a speci c lexical entry. Let's assume we select the lexical entry `krant' (newspaper). This produces the output given here in gure 1.10.

1.2 What example grammars/parsers/generators are provided? Currently the following scripts are built: TA : Ale 2.0 HPSG grammar, written by Bob Carpenter and Gerald Penn. [4], [5]. TL : HPSG grammar for Dutch using delayed evaluation techniques to implement recursive lexical rules (directory LexRules). Cf. [14, 2, 3]. TT : Small Tree Adjoining Grammar + 9 related head-corner parsing algorithms for headed Lexicalized and Feature-based TAG's (based on my paper on TAGs [13]). TG : DCG for Dutch, originally used as illustration for semantic-head-driven generation ([12, 11]. Furthermore, some of the parsers were used for the timings of the paper co-authored with G. Bouma on the potential eciency of head-driven parsing [1]. 4 The examples involving LATEX and trees are only available if Treemaker is installed. 5 In order for TreeMaker to adjust the vertical distances between nodes, we rst have to set the nodeskip ag to

an appropriate value. For this example I gaven the Prolog command set flag(nodeskip,120).

9

2

3

sign

cat : vp inv : +2

6 6 6 6 6 6 6 6 6 6 6 4

3

sign

subj : 4 cat : np 5 dir : left F f slash : G h sign cat : np

7 7 7 7 7 7 7 7 7 7  7 i 5

H







2 6 6 6 6 4

H

2

jan

6 6 6 6 6 6 4

ee

sign

cat : vp inv : + subj : F slash : G

   sign

3

sc : hFjIi 77 cat : vp 77 inv : + 77 subj : F 5

3 7 7 7 7 5

LL LL

LL L

F

slash : G

kust

marie

Figure 1.8: Hdrug output (via LATEX) of a tree of feature structure nodes.

10

Figure 1.9: Part of the lexical hierarchy of the TL application. The tree indicates that the de nition of the lexical entry `kus' (to kiss) is de ned in terms of the type `np transitive' which in turn is de ned in terms of the supertype `transitive', etc.

2 6 6 6 6 6 6 6 6 6 6 6 6 6 6 stem(krant; 666 6 6 6 6 6 6 6 6 6 6 6 6 4

3

sign

sc : hi 2

7 3 7 7 c0 7 6 index : sg&nneut&nhuman 7 7 7 7 sem : 64 fun : prime(krant) 5 7 7 7 restr : hi 7 7 cat : 2n 7 3 7 lexical 7 7 lex : 4 stem : krant 5 7 ): 7 word : krant 7 7 7 slash : hi 7 7 extra : hi 7 7 rel : hi 7 7 f slash : hi 7 7 f extra : hi 7 5 f rel : hi args : hi

Figure 1.10: Hdrug output (thru LATEX) of the de nition of the lexical entry `krant' (newspaper). This is only one of the readings of this noun. Furthermore, note that this example is produced while the add mod ag was disabled, to be able to let the output t on one page. Finally the TL application uses the ag `shorten' to indicate which attributes should be shown. For this example the value of this ag has been set to `o ' in order for all attributes to appear.

11

TC : Constraint-based Categorial Grammar for Dutch written by G.Bouma, slightly adopted by

G. van Noord for Hdrug. [2]. TD : The smallest possible DCG. Illustration what you need to do minimally to adapt a grammar / parser to Hdrug. TX : Extraposition grammar based on the paper by Pereira. Can also be used to nd out what you need to do to include a grammar into Hdrug. [9].

1.3 Comparison This package might be compared with Pleuk (by Jo Calder et al). One of the things of Pleuk that I didn't like was the use of the GM interface to Interviews (that comes standard with the Sicstus library). Using ProTcl it is possible in Hdrug to have Sicstus listen both to its ordinary input stream and to the Tk buttons and menus. At every moment you can decide to give ordinary prolog commands (keyboard), or rather use the mouse to get your parser (or whatever) into action. Also, I believe the Tk widgets look much nicer than the GM ones... :-), as Tcl/Tk provides `the Motif look and feel'. But note that Pleuk provides some functionality that is not available in Hdrug, such as a nice graphical derivation checker.

12

Chapter 2

Using the Hdrug Graphical User Interface It is not possible to give an overview of all the commands that are available, since each application might add new commands to the Hdrug core. This section therefore only discusses some of the basic commands and some of the commands that are used among di erent applications. In principle there are three ways to interact with Hdrug:  Using Prolog queries.  Using the Command interpreter.  Using Mouse-driven menu's and buttons. The rst two items are mutually exclusive: if the command interpreter is listening, then you cannot give ordinary Sicstus commands and vice versa. In contrast, the mouse-driven menu's and buttons can always be used. Prolog queries are given as ordinary Sicstus commands in the Sicstus widget. This way of interacting with Hdrug is generally not recommended, but it can be useful for low level debugging etc. Using the command interpreter can be useful for experienced users, as it might be somewhat faster than using the mouse (but note that in later versions almost all menu options can be selected using accelerators). The command interpreter is started by the Prolog predicate r/0 in the Sicstus widget. The command interpreter command p brings the Sicstus prompt back. Beginning users will nd the mouse-driven interface most useful.

2.1 Using the Mouse The Hdrug widget (cf. gure 1.1) contains the following sub-widgets (from top-to-bottom).   

MenuBar. The MenuBar contains a number of menubuttons. Each of these menu's is described below. ObjectBar. The ObjectBar is initially invisible. Once `objects' are produced by a parser or generator these objects will be placed on this bar. Two scrollable canvases. Each canvas is initially left blank but is used for graphical output such as parse-trees, etc. You can scroll the canvas using the scrollbars, but also using the middle mouse button. The relative size of the canvases can be adapted by dragging  ? ? the border with the left mouse button, or with the file  enlarge left canvas  resp. ?  enlarge right canvas commands. 13



ButtonBar. The ButtonBar contains three buttons that can be used to change the value of the top category, the parser and the generator. The current values of these are also listed next to the corresponding buttons. In gure 1.1 the top category is `main', the parser is `rcp3 dtrs' and the generator is `bug dd'. The checkbox use new canvas ?can be switched on in order for the next graphical output to be directed to a seperate window. Finally the rightmost button is a button that is added by the TL application, and which functions as an `About' button for this application.

2.1.1 The MenuBar The file ?Menu

The file ?menu contains buttons of which the meaning is rather straightforward. The rst items can be used to (re)compile grammar les. The detailed meaning is dependent on the application.  ? The compile prolog file button lets you choose a Prolog le which willbe compiled. The ?  ? reconsult prolog file button behaves similarlybut reconsults the le. The source tk/tcl file   ? button can be used to source a Tcl/Tk le. The halt button halts the application (really!). The enlarge left canvas ?and enlarge right canvas ?buttons adapt the relative size of the two canvases. It is also possible to restart the application. This implies that the graphical environment is restarted, but the application les are not reconsulted. This is useful if you are adding/debugging parts of the graphical interface. Use restart x ?to restart. quit x - keep prolog alive ?allows you to stop the interface, but continue the Prolog session.

The debug ?Menu

The debug menu contains a few buttons that are straightforward interfaces to the corresponding Sicstus predicates. It contains the options ?  nodebug  ?  debug  ?  remove spypoints spy ?  unspy predicate   ? statistics 

predicate ?

The options ?Menu

The options menu provides an interface to the ` ags' library, which ?implements global vari-? ?   ables in Prolog. The following options are provided: top category , parser , generator      , ?  ?  ?  ?  ? ?   useful try check , nodeskip , demo , object saving , ask and max objects . Applica            tions typically extend this list (via the menu ag/2 predicate of library(xtk)), or thru the Tcl menu ag procedure.

The parse ?Menu

The parse menu is a more interesting menu, although it consists of only a single button parse sentence ?. Pressing this button will present a dialog widget (cf. gure 1.2) asking you for a sentence. You can either type in a new sentence, or select one of the available test sentences. The available sentences are the sentences that were previously parsed during the current session, or that were listed in the test-suite, or that were the result of generation in the current session. The sentence you type or select will be parsed using the current parser, and the current top category. Some statistical output will be presented in the Sicstus widget. For each parse result a numbered object is created. Each object is visible as a button on the ObjectBar, allowing you to inspect each object (see 2.1.2). The maximum number of objects that is built is limited by the max objects ag. 14

The option compare parsers ?allows you to parse a single test sentence for each of the active parsers. Use the option parser selection ?to activate or de-active a particular parser.

The generate ?Menu

 generate

lf ? This option is the inverse of the parse option. Now you are prompted for a logical

 generate

object  This option takes the logical form from the object that you select, and

form, which is subsequently input to the current generator. Again, you can either specify a logical form `by hand' or select a pre-existing logical form. Note that there is (yet) no concept of a test-suite for logical forms. ?

generates from this logical form. Note that other information of this object is not taken into account in the generation process.

 generator

selection ? Use this option to activate or de-activate a particular generator.

 compare

generators on lf ? Generate from a given logical form for each of the active gener-

 compare

generators on object  Generate from the logical form of a given object for each

ators.

?

of the active generators.

The test-suite ?Menu

The test-suite menu contains a number of options in order to test the application for a (pre-de ned) set of sentences. This set of sentences is de ned in a le called suite.pl in the application directory, and consists of a number of Prolog clauses for the predicate sentence/2, where the rst argument is a unique identi er of that sentence, and the second argument is a list of atoms. Note that there is (yet) no concept of a test-suite for logical forms. The following options are provided. test-suite ? If this option is chosen then all sentences are parsed in turn, for each of the parsers that are `active'. Use the parser selection ?option to select the parsers you want to  run

include/exclude for the run.

 run

?

test-suite and view  This option behaves similar to the previous option, but in addition

statistical information comparing the di erent parsers is shown in a separate TK widget. The statistical information is updated after a sentence has been parsed by all active parsers.  reload

test-suite ? Choosing this option reloads the test-suite. Note that it does not destroy

existing test-results.

 view

?

test-results  This option contains a number of sub-options that allow you to view the

test-results in various ways.  individual

?

tk 

Presents a graph in which the length of the sentence is plotted against the parse time, for each of the di erent parsers and sentences. ?

 totals

per #words tk 

 totals

per #words latex 

Similarly, but now averages per sentence length are used. ?

15

This produces an Xdvi window containing a table of the parse results, again averaged over sentence-length. Note that all LATEX les are placed in a temporary directory, given by the environment variable $TMPDIR. If this variable is not set, the directory /tmp is used. The predicate latex:files/5 can be used to get the actual le names that are used.  totals

?

per #readings latex 

This produces a table of the parse results, averaged over the number of readings.

 individual

?

prolog 

This simply gives a Prolog listing of the table entry/6 predicate.

 totals

?

per #words prolog 

Prolog output of the average cputimes per parser per #words. This is given as a list of terms t(Length,Time,Parser) with the obvious interpretation.  destroy

predicate.

?

test results  Removes the test-results, i.e. retracts all clauses of the table entry/6

The view ?Menu

The view ?Menu contains several sub-menus indicating the type of things you can view. Typically, you can view `objects' (the result of parsing and generation) `predicates' (Prolog predicates) and `types' (if your application uses library(feature). For each of the sub-menus you can choose between di erent output widgets: Tk, Prolog and LATEX. Finally, for each combination of `thing' and `output widget' you can choose between a number of di erent output lters. The choice of lter determines whether the output is printed as a tree, a feature structure or the internal Prolog encoding. Note that Hdrug starts the Xdvi application only once. If you happen to have deleted the Xdvi application you can re-start it by the Sicstus command xdvi/0. Note that not all view options will produce results. Sometimes these options are only de ned for particular inputs. For example, in the TT application there are parsers that build derivation trees, and there are parsers that build derived trees. Hdrug is not always able to tell in advance whether e.g. the Tree(dt) lter (for derivation trees) is de ned for a particular object.

The help ?Menu

The Help Menu is underdeveloped at the moment. The Help button is an interface to Sicstus' help/0 predicate. This is only useful if an application de nes the predicate user help/0. The About button produces a rather ugly picture of the author of Hdrug. The Version button produces some information concerning the version of Sicstus, Hdrug and application. Finally some applications add an extra `About the Grammar' option that mentions the authors of the application.

2.1.2 The ObjectBar

The results of parsing and generation are asserted in the database as `objects'. The existence of objects is indicated in the ObjectBar. For example, if we have parsed the sentence `jan kust marie' in the TL application, then the ObjectBar contains two buttons, labeled `1' and `2', indicating the rst and second parse result. Pressing the button gives rise to a submenu containing three options. The rst option allows inspection of the object. The possibilities are essentially those described above under the view ?Menu. The second and third option allow the generation from the logical form representation of the object (if the application in fact de nes a generator), either for the current generator, or for all active generators.

16

2.1.3 The ButtonBar

The ButtonBar contains maximally three buttons that can be used to change the value of the top category, the parser and the generator. The current values of these are also listed next to the corresponding buttons. In gure 1.1 the top category is `main', the parser is `rcp3 dtrs' and the generator is `bug dd'. Finally the rightmost button is a button that is added by the TL application, and which functions as an `About' button for this application. Note that there is only a generator ? button if there are generators de ned; similarly the parser ? button might not exist in some applications.

2.2 The Command-interpreter Most of the functionality described above is available through a simple command-interpreter as well. The command interpreter is entered by the Sicstus command r/0. The command interpreter is exited by the command interpreter command p . Commands for the command interpreter are always ended with a . Commands do not expect a dot at the end. The command-interpreter features a history and an alias mechanism. It allows also some redirection of output to les, escape to Unix, and is easily extendible by an application. A command is typed in by the user as one line of text The following meta-devices apply: All occurences of $word are replaced by the de nition of the alias word. The alias command itself can be used to de ne aliases: 19 |: alias hallo ! cat hallo 20 |: $hallo

so command number 20 will have the same e ect as typing 33 |: ! cat hallo

and if this command had been typed as command number 33 then typing 35 |: $33

gives also the same result (history mechanism works only for last 20 commands). Moreover, if no alias has been de ned, then it will apply the last command that started with the name of the alias: 66 |: parse john kisses mary 67 |: $parse

Both commands will do the same task. Each command may be ended by > File to indicate that output has to be redirected to a le. A message will be issued if le already exist, and the user will be prompted for an optional other le name. Note that commands try to eat their arguments maximally, so: 40 |: ! cat hallo > hallo2

is interpreted so that the output redirection is part of the shell command (and hence there will be no warning if the le hallo2 exists!). The following lists a number of useful commands. Note that applications typically extend this list.

Command Options Files rc fc c ld lib

File File File File File

Description reconsults le File(.pl). fcompiles le File(.pl). compiles le File(.pl). loads le File(.ql) ensure loads library(File). 17

Command Options libc librc

Debug p quit break spy spy ! cd

File File

Description

compiles library(File). reconsults library(File).

Pred/Ar Module Pred/Ar Cmd Dir

exits command interpreter. exits Hdrug. forces Prolog break. sets spy-point on Pred/Ar. sets spy-point on Module:Pred/Ar. Cmd is passed on to Unix. change directory to Dir.

lg rcg lg rcg

Files Files

Compile grammar. Reconsult grammar. Compile grammar les Files. Reconsult grammar les Files.

top

Top

pm gm only

Parser Generator Parsers

ag

Flag

de nes the top-category for parsing and generation. makes Parser the current parser. makes Generator the current generator. make Parsers the only active parsers and generators. prints the value of ag Flag (cf library( ags)).

Words

Parse the sentence made up of Words.

LF LF

Generate the logical form LF. Generate the logical form LF for all active generators.

pc

Words

rt go go

Id

Parse the sentence made up of Words for all active parsers. Destroy test results. Run test-suite. Compare parsers on sentence with identi er Id. Listing of available sentences. Print results of test-suite (as a Prolog listing). make Parsers/Generators inactive. make Parsers/Generators active. Tk output of test-suite results (individual). Idem, but only for Parsers.

Grammar

Options

Parse Generate gc

Test suite

sentences pt no yes sts sts

View

Parsers/Generators Parsers/Generators Parsers

18

Command Options s

Description

Type Output Thing(s) will show Thing(s). Type is one of `i, j s, w, f, Tree', of which the interpretation is `Prolog internal', `Prolog internal using print', `semantics', `words', `feature structure' and `tree(Tree)'. Output can be x (for LaTeX), tk (for Tk) or left blank (for Prolog output). Things is a list of integers indicating the objects, or a speci cation of a de nition. Consider the following examples: 4 |: s j 1 vp 5 |: s s 1 [kus(marie,jan)] 6 |: s w 1 jan kust marie 7 |: s x f 1 => xdvi output of a feature structure

w type

Type Output Word Type

gtype

Type

Note that the use of the Mouse-driven interface is recommended for viewing objects and de nitions. View lexical entry Word. prints the type tree of type Type. Only useful if the application uses library(feature). If no type is given, then top is assumed. as the type command, but the type tree is given in tree format.

19

Chapter 3

De ning an Application in Hdrug 3.1 General Setup For an application to work with the Hdrug system, there are a number of predicates you have to supply. Furthermore, you can extend the Hdrug system with application-speci c options. Finally, you can always overwrite existing Hdrug de nitions. In this chapter I discuss the various possibilities.

3.1.1 Files

It is assumed that an application is de ned as a number of les in some directory. The general setup of this directory is recommended to be as follows.

Make le Firstly, there will be a Makefile which can be used to build the application. This Make le should have two targets: one for script and one for state. Furthermore, it usually includes the con guration le from the Hdrug directory. A typical Make le, taken from the TD application, is de ned as follows: STATE_OR_SCRIPT=script BINDIR=$(HOME)/bin HDRUG=/usr/local/src/Hdrug2.4/Hdrug/Prolog/hdrug sppath=/usr/local/src/Hdrug2.4/protcl1.4/Static/sp TD : $(STATE_OR_SCRIPT) install : cp TD $(BINDIR) state : start.pl decl.pl gram.pl parser.pl generator.pl ( echo "compile(start).";\ echo "initialization(x).";\ echo "save_program(state).") | $(HDRUG) -f echo '#!/bin/sh' > TD echo "( cd `pwd`" '; $(sppath) -r state -f $$@)' >> TD chmod +x TD script : echo '#!/bin/sh' > TD echo "( cd `pwd`" '; $(HDRUG) -f -l x $$@ )' >> TD chmod +x TD

20

Note that instead of the variable assignments at the top of the le you could also include the Make le.defs le from the Hdrug distribution.

start.pl It is assumed that the le start.pl contains the directives and de nitions to load all the les of the application, and to compile (if neccessary) the appropriate grammar les, etc. As an example of a start.pl le, we again use the TD application.

:::::-

compile(decl). compile(gram). compile(suite). compile(parser). compile(generator).

The application TD is de ned by a number of Prolog les. The le decl.pl contains a number of declarations. These essentially establish the connection between the application and Hdrug. The le gram.pl contains the De nite Clause Grammar. The le suite.pl contains a number of example sentences. The les parser.pl and generator.pl are the parser and generator respectively.

x.pl Furthermore, the le x.pl, which is used in the script, simply consists of a directive to compile the start.pl le, followed by the command to start the X environment. Hence x.pl is de ned as: :- ensure_loaded(start). :- x.

3.2 Parsers and Generators

3.2.1 Declaration of parsers and generators

In Hdrug you can de ne any number of parsers and generators. A parser and generator is identi ed by an atomic identi er. A parser is declared by the Sicstus directive: . :- flag(parser(Identi er),OnofO ).

Similarly, a generator is declared by: :- flag(generator(Identi er),OnofO ).

This de nes a parser of generator and moreover tells Hdrug whether this parser is active or not. Only if a parser is active, it will be used in test-suite runs. Not only should the application de ne which parsers and generators exist, but usually it will also de ne the `current' parser and generator. This is achieved by initializing the parser and generator ag. :- initialize_flag(parser,Identi er). :- initialize_flag(generator,Identi er).

Summarizing, there exist a number of parsers. A subset of those parsers are active. One of the parsers is the current parser.

3.2.2 Predicates provided by a parser and generator

If a parser (generator) is de ned, then there should be a module with the same name which provides the following predicates. Note that only the rst one of these predicates, parse/1 or generate/1, is obligatory. The others are not. 21

/ generate/1 This predicate is the predicate that does the actual parsing (generation). At the time of calling, the argument of the parse/1 (generate/1) predicate is a term o(Obj,Str,Sem) where Obj is a term in which the top-category is already instantiated. Furthermore, part of the term might be instantiated to some representation of the input string (in case of parsing if the predicate phonology/2 is de ned) or some representation of the input logical form (in case of generation if the predicate semantics/2 is de ned). But note that the string and logical form are also available (if instantiated) in the second and third argument of the o/3 term. count/0 This optional predicate is thought of as a predicate that might produce some statistical information e.g. on the number of chart edges built. Note that library(count edges) contains predicates to count the number of clauses for a given predicate. count/1 Similarly, but this time the argument should get bound to some integer. The argument of this predicate determines the nal argument of the table entry/6 predicate in test runs. clean/0 If the parser adds items, chart edges etc. to the database, then this predicate de nes the way to remove these again. start hook/4 This predicate is a hook that is called before the parser starts. Its rst argument is either the atom parse or the atom generate (any idea what that means?); the second argument is the parser or generator mode (hence the name of the module); the third argument is the object (an o/3 term). The fourth argument can be anything. It is provided to pass on information to the next two hook predicates. For example, the predicate could pass on information concerning the current memory usage of Sicstus. This information could then be used by end hook to compute the amount of memory that the parser has consumed. result hook/4 This predicate is a hook that is called each time the parser / generator succeeds in nding a parse / generation. The predicate takes the same arguments as start hook/4. For example, this predicate could be used to provide a pretty printed tree of the parse result in the Tk Canvas. end hook/4 This predicate is a hook that is called if the parser / generator can not nd any results anymore. Again the arguments are the same as for the two hook predicates above. Note that at the moment of calling this predicate the object will typically not be instantiated. parse/1

3.3 Top categories Usually a grammar comes with a notion of a `start symbol' or `top category'. In Hdrug there can be any number of di erent top categories. These top categories are Prolog terms. Each one of them is associated with an atomic identi er for reference purposes. Each top category is de ned by a clause for the predicate top/2, where the rst argument is the atomic identi er and the second argument is the top-category term. For example: top(s,node(s,_)). top(np,node(np,_)).

The ag `top features' is used to indicate what the current choice of top-category is. Usually an application de nes a default value for this ag by the directive: :- initialize_flag(top_features,Identi er).

22

3.4 Strings and Semantics The predicate semantics/2 de nes which part of an object contains the semantics (if any). For example, in the TD application categories are generally of the form node(Syn,Sem). Therefore, the following de nition of semantics/2 is used: semantics(node(_,Sem),Sem).

The predicate is mainly used for generation. By default, the predicate is de ned as semantics( , ). In a similar way, the predicate phonology(Node,Phon) can be de ned. This is only useful for `sign-based' grammars in which the string to be parsed is considered a part of the category. The default de nition is phonology( , ). The predicate extern sem/2 can be used to de ne a mapping between `internal' and `external' formats of the semantic representation. This predicate is used in two ways: if a semantic representation is read in, and if a semantic representation is written out. For an extensive example consider the TL application. The rst argument is the external representation, the second argument the internal one. The default de nition is extern sem(X,X).

3.5 Grammar compilation

1 Currently, the grammar ?menu contains four distinct options to recompile (parts of) the gram-

mar. It is assumed that if an application is started, the grammars are already compiled. These options will thus be chosen if the grammar has to be recompiled (e.g. because part of the grammar has been changed). The following four predicates have to be provided by the application. If these predicates do not ful ll your needs, you can always extend the grammar menu (cf. below), or even overwrite it (as in the TA application). compile grammar/0 should recompile the whole grammar. reconsult grammar/0 should recompile the whole grammar. If les are to be loaded, then `reconsult' is used rather than `compile'. This allows easier debugging. compile grammar file/1 should recompile the grammar le that is its argument. reconsult grammar file/1 idem, but uses reconsult where appropriate.

3.6 The Test-suite The le suite.pl should contain a number of example sentences. This set of sentences in e ect consists of a number of Prolog clauses for the predicate sentence/2, where the rst argument is a unique identi er of that sentence, and the second argument is a list of atoms. For example: sentence(a,[john,kisses,mary]). sentence(b,[john,will,kiss,mary]).

Note that there is (yet) no concept of a test-suite for logical forms. The le suite.pl might also contain a de nition of the predicate user max/2. This predicate is used to de ne an upper time limit, possibly based on the length of the test sentence (the rst argument), for parsing that sentence in a test-suite run. By default, Hdrug behaves as if this predicate is de ned as follows: user_max(L,Max) :Max is 10000 + (L * L * 300).

1 This part of Hdrug is likely to change: : :

23

Statistical information for each parse is preserved by the dynamic predicate table entry/6. The arguments of this predicate indicate: 1. an atom (the unique identi er of the sentence) 2. an integer (the length of the sentence) 3. an integer (the number of parses of the sentence, i.e. the degree of ambiguity) 4. an atom (the name of the parser) 5. an integer (the amount of milliseconds it took to parse the sentence. In case of time-out the atom `time out'). 6. a term (often used to indicate the number of chart-edges built). It is determined by the count/1 predicate.

3.7 Extending the Graphical User Interface It is easy to extend the Graphical User Interface for a speci c application. There are two predicates that you can de ne. The rst predicate, gram startup hook begin/0 is called at the beginning of the loading of SP hdrug.tcl, whereas the predicate gram startup hook end/0 is called at the end of the loading of this le. Usually the appropriate thing to do is to de ne the latter as in the following example. This example is taken from the TD application. The predicate simply sources an application speci c Tcl/Tk le. gram_startup_hook_end :tcl_eval('source $hdrug_library/SP_dcg.tcl').

The le `SP dcg.tcl' is a Tcl/Tk source. If you're not familiar with Tcl/Tk, read Ousterhout's excellent introductory book [8].

N.B. Note that Tcl/Tk commands should only be issued if the Tcl/Tk interpreter is actually running, i.e. after the x/0 command has been issued.

3.8 Extending the Command Interpreter It is possible to add commands to the command interpreter using the linking technique described in section 4.2. The idea is that you can de ne a ternary relation with a name of your choice. This relation is declared inside the following pair of directives: :- del_command(PredName).

De nition of PredName/3

:- add_command(PredName).

This ternary relation is best de ned as grammar rules; since the idea will be that the rst argument is a command to be called, and the second and third argument represent the command that was typed in (as a di erence list of words). For example, consider the case where we want the command rx to restart the Tcl/Tk interface. Furthermore, an optional argument of `0' or `1' indicates whether the shell should be stolen upon restart. This could be de ned as follows: :- del_command(mycmd). mycmd(restart_x(Arg)) --> [rx], rxarg(Arg). rxarg(1) --> [1]. rxarg(0) --> [0]. rxarg(0) --> []. :- add_command(mycmd).

24

3.9 Viewing Prolog De nitions If you want to use Hdrug's built-in facilities to view Prolog clauses, then it is neccessary that these clauses are accessible via the predicate user clause/2. The arguments of this predicate are the head and the body of the clause respectively. The reason that Hdrug does not use the built-in clause/3 predicate, is that this predicate is only available for dynamic clauses. The easiest way to obtain user clause/2 de nitions is to provide a term expansion de nition with the appropriate e ect. To understand the following example, refer to the discussion of the term expansion library in 4.1. In the following example all clauses are available as user clause/2 as long as the ag `make user clause' is on: :- del_expansion(make_user_clause). make_user_clause(Head,Body,Head,Body). % passes original definition make_user_clause(Head,Body,user_clause(Head,Body),[]) :flag(make_user_clause,on). % builds user_clause/2 :- add_expansion(make_user_clause).

By setting the ag `on' or `o ' it is possible to select the appropriate clauses for which you want viewing to be possible. A similar technique is used in the TL application.

25

Chapter 4

The Hdrug Library 4.1 Term Expansion The term expansion library is an attempt to provide extended functionality for term expansion. It should improve upon the standard way of doing term expand because it is possible to:   

use delayed constraints both in compiled and reconsulted les (this is achieved by pushing constraints `back into the body'). gives rise to more than one result if the term expansion predicates give more than one result. allows a series of term expansion predicates (the output of a term expansion predicate can be the input for the next).

The predicates adda expansion/1, add expansion/1, addz expansion/1 and del expansion/1 are available to add resp. delete a term expansion predicate. In each of these predicates the argument is an atom representing the predicate symbol of the predicate. The a and z sux indicates whether the predicate should be added to the front or to the end of the list of term expansion predicates. This list is available via the ag expansion list. Its value upon starting Hdrug is: [feature:eval_head_body,dcg_expansion]

The rst predicate is added by the feature library. 1 The second will take care of the ordinary DCG grammar rule compilation. A term expansion predicate invariably takes four arguments. These arguments resp. represent the head and body of the input clause, and the head and body of the resulting clause. Multiple outputs are handled thru backtracking. Note that bodies are represented here as lists of goals. Queries and goals are not a ected by the term expansion library. The term expansion facility can be debugged by setting the ag trace exp to on. Term expansion does the following. Given a list of term expansion predicates p1 : : :pn and an `input' clause h :- b. For each of the solutions of the query

p1 (h; b; h1; b1); p2(h1 ; b1; h2; b2); : : :; pn(hn?1; bn?1; hn; bn) with the pending constrains , we assert the clause hn :- ; bn. on

1 but note that this term expansion predicate only a ects a de nition if in turn the ag eval feature is set to

.

26

4.2 Link Clauses In various places it is useful to have predicates that can be de ned in multiple places. For some discussion and techniques that are de ned in this library refer to [7]. The library provides two predicates: add linking clause/3 and del linking clause/3. If you call the add linking clause predicate with arguments Link, Pred and Arity then the predicate Pred(A1 : : :AArity) :- Link(A1 : : :AArity) will be asserted. 2 Unsurprisingly, the del linking clause predicate does a retract instead of an assert. If you want to use the linking clause technique to de ne multiple de nitions of the portray/1 clause, you can use the abbreviations add portray/1 and del portray/1.

4.3 Flags Hdrug manages a number of `global' variables thru a agging mechanism, that is de ned in library( ags). This library is based on [10]. A ag consists of a ground key (the `global variable') and a value (arbitrary Prolog term). The most important predicates are: flag(?Flag)

is true if Flag is a ag. Can be used to enumerate all global ags thru backtracking.

is true if Flag currently has value Val. flag(+Flag,?Old,?New) is true if Flag currently has value Old. After calling the predicate the value of Flag will be New. set flag(+Flag,?Val) sets ag Flag to Val. It is equivalent to flag(Flag, ,Val). initialize flag(+Flag,?Val) sets ag Flag to Val only if Flag currently unde ned. flag(+Flag,?Val)

Some ags can be used to store multiple values. In this case the following predicates are relevant. add flag(+Flag,?Val adds the value Val to the list of values of Flag, unless Flag already contains Val. del flag(+Flag,?Val removes Val (if possible) from the values of Flag. member flag(+Flag,?Val) Val is one of the values of Flag. Often the global variables need to be passed on to Tcl/Tk. For this purpose there exists a Tcl/Tk array variable, called ` ag'. The following predicates can be used to communicate ags between Prolog and Tcl/Tk. Note: these predicates all asssume that Tcl/Tk is running at the time the predicate is called. send flag(+Flag) sets the Tcl/Tk variable ag(Flag) to the current value of the Prolog ag Flag. send flag(+Flag,Old,New) is equivalent to the conjunction of goals flag(Flag,Old,New), send_flag(Flag) send flag(+Flag,New)

is equivalent to send flag(Flag, ,New).

2 The actual e ect is somewhat di erent as the library tries to take modules into account.

27

4.4 Trees The libraries tk tree, p tree and latex tree contain extensive possibilities to produce output in the form of trees. Only a few declarations are needed to de ne what things you want to see in the tree. In e ect, such declarations de ne a `tree format'. In Hdrug, there can be any number of tree formats. These tree formats are named by a ground identi er. A tree format consists of three parts: the path de nition indicates what part of the object you want to view as a tree; the label de nition indicates how you want to print the node of a tree; and the daughter de nition indicates what you consider the daughters of a node. For example, the following predicates de ne a tree-format called `s' (this example is taken from the `TD' application). gp(s,node(_,S),S). gl(s,Term,Label) :functor(Term,Label,_). gd(s,1,Term,D) :arg(1,Term,D). gd(s,2,Term,D) :arg(2,Term,D).

The rst predicate de nes that we want to take the semantics part of a node as the term that we want to view as a tree. The second predicate de nes that for a given tree Term we want to print its functor as the node label. Finally the third predicate de nes that for a given tree Term the rst daughter is to be the rst argument of the term, and the second daughter is to be the second argument. Because we want to be able to have multiple tree formats around, we cannot simply de ne a tree format in an application using Prolog predicates, as this would erase the existing tree formats. Therefore, we use a `link-clause' technique from [7] to add de nitions to existing de nitions. In the case at hand, this is done using two directives. Right after a tree format de nition, we have a directive of the form: :- add_graphic(PathPred,DaughterPred,LabelPred).

where the arguments are the predicate names of the predicates that we want to use for the de nition. In fact, what this directive does is to add the clauses: graphic_path(A,B,C) :- PathPred(A,B,C). graphic_label(A,B,C) :- LabelPred(A,B,C). graphic_daughter(A,B,C,D) :- DaughterPred(A,B,C,D).

In order to be able to reconsult les consisting of tree format de nitions we will also delete these de nitions before we add them. Right before a tree format de nition, therefore, we have a directive of the form: :- del_graphic(PathPred,DaughterPred,LabelPred).

where the arguments are the predicate names of the predicates that we want to use for the de nition. In fact, what this directive does is to delete the dynamic clauses: graphic_path(A,B,C) :-

PathPred(A,B,C).

graphic_label(A,B,C) :-

LabelPred(A,B,C).

graphic_daughter(A,B,C,D) :-

DaughterPred(A,B,C,D).

28

As another example of a tree format de nition, consider the `TC' application. Here we nd: :- del_graphic(gp,gl,gd). gp(syn,Obj,Obj). gl(syn,tree(Sign,_,[_|_]),Label) :cat_symbol(Sign,Label). gl(syn,tree(W,_,[]),W). gd(syn,No,tree(_,_,[H|T]),D) :nth(No,[H|T],D). :- add_graphic(gp,gl,gd).

Here, objects generally are of the form tree(Node, ,ListOfDs). Therefore, the path part of the tree format de nition simply uni es the object and the tree part. The label part of the tree format de nition distinguishes two cases. If there are no more daughters, then the node is a terminal, and this terminal is simply taken to be the node label. In the other case the node label is de ned by a seperate predicate `cat symbol'. This predicate changes the internal representation into some more readable format. Finally, the daughter part of the tree format de nition uses the Sicstus library predicate `nth'. The e ect of the de nition is that the rst daughter is the rst element of the daughter list, etc.

Tk Output The tk tree module de nes the predicate tk tree/2. This predicate outputs a tree

to the Canvas widget. The rst argument is the name of a tree lter. The second argument is an arbitrary Prolog term on the basis of which the tree is computed. If the tree is output thru the Tk/Tcl canvas, then the nodes of the trees are buttons. For each tree format we can de ne what action should be undertaken if a button is pressed. This is de ned by the predicate show node/2. The rst argument is the identi er of the tree format, the second argument is the current node (note: this is not the label as de ned by graphic label, but the term on the basis of which graphic label is de ned). The following de nition, from the TC application, prints the node as a feature structure in a separate Tk window (the predicate tk fs/1 is available from the feature library). show_node(syn,tree(Sign,[_|_],_)) :tk_fs(fs(Sign)).

If this predicate is not de ned then the label will simply be written out to the Sicstus widget.

New in 2.5 Similarly, the predicates show node2/2 and show node3/2 can be used to de ne an action for pressing the second and third mouse-button respectively.

LATEXoutput The latex tree module de nes the predicate latex tree/2. This predicate writes

a tree in LATEXand calls the appropriate shell commands to get Xdvi to display the tree. The rst argument is the name of a tree lter. The second argument is an arbitrary Prolog term on the basis of which the tree is computed. Use the predicate latex:files/5 to nd out what the names of the LATEX les are

Sicstus output Ordinary Sicstus output is available through the p tree module. This module de nes the predicates pretty graphic/2. The rst and second arguments are the tree- lter name and an arbitrary term.

29

Trees of feature structures Trees in which each of the nodes is a feature-structure are sup-

ported for Tk output (if you use Hdrug with the TkTree extension) and LATEXoutput. Nodes are interpreted as a description of a feature-structure if the tree format identi er matches matrix( ). For some examples refer to the TL,TT, and TC applications.

4.5 The feature library The feature library provides extensive possibilities to compile feature equations into Prolog terms, and to view such compiled Prolog terms as feature-structures. The motivationfor such an approach might be that you want feature structures for readability on the one hand, but Prolog terms and Prolog uni cation of such terms for eency reasons internally. The package is heavily in uenced by the work of Chris Mellish [6].

4.5.1 Types

Before feature structures can be compiled into terms, a number of type declarations need to be speci ed. The declarations that need to be de ned are top/1, type/3 and at/1. These three de nitions de ne a type hierarchy. This hierarchy has the shape of a tree. The top/1 de nition de nes the daughter nodes of the root of the tree. This root is always called `top'. Attributes can be attached to a single type in the type hierarchy. If a type is associated with an attribute then this attribute is inherited by all of its subtypes. The top node of the type hierarchy can be seen as a variable. You can not specify any attributes for this type. The type/3 predicate de nes for a given type ( rst argument) a list of subtypes (second argument) and a list of attributes (third argument). The at/1 de nitions de ne terminals of the tree that do not introduce attributes. It is an abbreviation of a type/3 de nition in which the second and third argument are both the empty list. 3 As an example, consider the following type tree de nition: top([boolean,sign,cat]). type(boolean,[+,-],[]). at(+). at(-). type(sign,[],[cat,phon,sem]). type(cat,[noun,verb],[agr]). type(noun,[],[pro]). type(verb,[],[aux,inv,subj]).

If this type de nition is consulted by Hdrug, and if the directive: :- type_compiler.

is called, then it is possible to view the type de nition by choosing view ?type ?tk ?. This gives rise to a tree on the canvas ( gure 4.1). The meaning of such a type tree can be understood as follows. The class of objects is divided in three mutually exclusive subclasses, called boolean, sign and cat. Objects of type boolean can be further subdivided into classes + or -. Objects of type sign can be further speci ed for a cat, phon or sem attribute. The meaning of this type tree can also be understood by looking at the way in which objects of a certain type are represented as Prolog terms. This is illustrated in gure 4.2.

3 define type/5 can be used to de ne multiple sets of subtypes, and constraints on types. The latter should be used with great care.

30

Figure 4.1: A simple type tree. Some types are associated with attributes.

SubType HHH    HHH    HH  boolean(SubType, ) sign(Cat,Phon,Sem, ) cat(SubType,Agr, ) , ll ,  TT , ll TT ,,  l

boolean(+) boolean(-)

cat(noun(Pro),Agr) cat(verb(Aux,Inv,Subj),Agr)

Figure 4.2: The type tree: all types are replaced with their encoding as Prolog terms.

31

4.5.2 Equational constraints

If the type de nition is compiled, then the following predicates can be used: /2, =>/2, ==>/2. The rst predicate equates two paths, the second predicate assigns a type to a path, and the third predicate assigns an arbitrary Prolog term to a path. A path is a Prolog term followed by a sequence of attributes, seperated by a colon (:). Therefore, given the previous example of a type tree, we can have the following equational constraint: X:cat => noun. X = sign(_H,cat(noun(_G,_F),_E,_D),_C,_B,_A) Y:cat:agr Y:cat:subj:cat:agr. Y = sign(_O,cat(verb(_N,_M,_L,sign(_K,cat(_J,_E,_I), _H,_G,_F)),_E,_D),_C,_B,_A) Z:phon ==> [jan,kust,marie]. sign(_D,_C,[jan,kust,marie],_B,_A)

4.5.3 Viewing Prolog Terms representing Feature Structures

Note that a couple of predicates are available to view Prolog terms as feature structures. For example, the predicate tk fs/1 from the feature library can be used to view a term in a Tk window. For example, you might try the conjunction: Y:cat:agr Y:cat:subj:cat:agr, tk_fs(fs(Y)).

New in 2.5 The use of constraints is now supported too. Furthermore, you can de ne the

relation show relation/1 to de ne an action for pressing the rst mouse-button on a relation name. The argument is a Functor/Arity pair. For example,

show_relation(F/A) :show_predicate(F/A,fs,tk).

will show the predicate de nition. The query

Y:cat:agr Y:cat:subj:cat:agr, latex_fs(fs(Y)).

produces: 2 6 6 6 6 6 6 6 4

sign 2 6 6 cat : 666 4

3

verb

agr : A2

sign 

subj : 4 cat : cat agr : A

7 3 7 7 7  5 7 5

3 7 7 7 7 7 7 7 5

But if you insist on ordinary output, try: tty_fs(X).

This produces: {sign} |cat {verb} | |agr | |subj {sign} | | |cat {cat} | | | |agr .

Not only can you view feature structures this way, but also clauses. Examples can be found in the TL application. 32

4.5.4 Lists

You can add (ordinary Prolog) lists to your type tree by the simple de nition: list_type(HeadAtt,TailAtt).

This will allow the use of attributes HeadAtt and TailAtt for referring to parts of lists. Furthermore, lists of typed objects will be shown appropriately. For example: [-user]. | list_type(h,t). | {user consulted, 20 msec 48 bytes} ^D yes | ?- X:t:h:cat => verb. X = [_A,sign(_K,cat(verb(_J,_I,_H,_G),_F,_E),_D,_C,_B)|_L] ? yes | ?- X:t:h:cat => verb, latex_fs(fs(X)). [1] 6835 X = [_A,sign(_K,cat(verb(_J,_I,_H,_G),_F,_E),_D,_C,_B)|_L] ?

produces: 

h

; sign cat : verb

 ji

4.5.5 Extensionality

Direct subtypes of type `top' are represented using an extra variable position. This is to make sure that objects are only identical if they have been uni ed. For some types, such as `boolean', this does not make much sense. Types that you want to consider as `extensional' in this way are to be declared with the predicate extensional/1. The following example illustrates the di erence. Without the extensional predicate we have: X:inv => -, X:aux => -, tty_fs(X). {verb} |aux {-} |inv .

After declaring that boolean and `-' be extensional types (and recompiling the type tree), we get: X:inv => -, X:aux => -, tty_fs(X). {verb} |aux {-} |inv {-}.

The di erence is that Hdrug does not show explicitly that the values of aux and inv are the same in the second example. This is redundant information because objects of extensional types always are the same if they have the same information content.

4.5.6 Unify except

The library provides the predicates unify except/3, unify except l/3 and overwrite/4. The rst argument takes two feature terms and a path. The rst and second argument are uni ed except for the value at the path. As an example (assuming the simple type system given above), we might have: 33

| ?- unify_except(X,Y,cat:agr). X = sign(_G,cat(_F,_E,_D),_C,_B,_A), Y = sign(_G,cat(_F,_H,_D),_C,_B,_A) ?

The predicate unify except l is similar, except it takes a list of paths rather than a single path as its third argument. Finally, the predicate overwrite/4 can be understood by looking at its de nition: overwrite(FS,FS2,Path,Type) :unify_except(FS2,FS,Path), FS2:Path => Type.

4.5.7 Find type

The meta-logical predicates find type/2 and find type/3 can be used to get the most speci c type of a feature term. The rst argument is the feature term, the second argument is a list of most speci c types (for simple usage just consider the rst element of this list). The optional third argument is a list of attributes that are appropriate for this type. For example: | ?- X:agr X:subj:agr, find_type(X,[Y|_]). X = cat(verb(_G,_F,_E,cat(_D,_B,_C)),_B,_A), Y = verb ?

It is clear that find type/2,3 is a meta-logical predicate by looking at the following example, where the conjuncts are swapped: | ?- find_type(X,[Y|_]), X:agr X:subj:agr. X = cat(verb(_G,_F,_E,cat(_D,_B,_C)),_B,_A), Y = top ? ;

4.5.8 Term expansion

The feature library also comes with a term-expansion package (consistent with the term expansion library). This package allows for very compact de nitions of feature structures. The package will only work if the `eval feature' ag is set to on. In that case les containing Prolog de nitions will be compiled as follows. All terms occurring in such de nitions will be replaced according to the following rules. is replaced by Term. This functions as an escape: Term is not further compiled by the expansion package. X:Y (a path) is replaced by Z, where Z X:Y.  X (a type) is replaced by Z, where Z => X. @X (a macro) is replaced by Z, where Z(X). X&Y is replaced by Z, where X Y Z.

fTermg

Furthermore, the goals , ==>, =>, unify except/3, are partially evaluated.

34

unify except l/3

and overwrite/4

Extending term-expansion An application can add its own syntactic sugar by de ning the following predicates. Firstly the predicate eval a call/2 informs Hdrug that a particular goal (matching the rst argument) should be partially evaluated. The second argument is the atom `no' or `yes' depending on whether the arguments of that call should be subject to term-expansion or not. Secondly the predicate user eval/2 determines whether a particular term should be altered by term-expansion. The rst argument is the input term, the second argument is the desired result of replacing the rst argument.

4.5.9 Disjunction and Negation over Atomic Values

A special mechanism is provided for atomic values to allow for disjunction and negation over such atomic values. These atomic values are not declared in the type-system as shown above, but rather they are introduced by the predicate boolean type/2. The rst argument of this predicate is an identi er, the second argument of this predicate is a list of lists that is understood as a set product. For example, agreement features could be de ned as: boolean_type(agr,[[1,2,3],[sg,pl],[mas,fem,neut]])

So valid and fully speci ed values for agreement consist of an element from each of the three lists. The syntax for type-assignment is extended to include disjunction (';'), conjunction ('&') and negation ('~') of types. For example, to express that X has either singular masculine or not-second person agreement, we simply state: X => ( sg & mas ; ~2 ).

The following example illustrates the use of this package: | ?- [-user]. | boolean_type(agr,[[1,2,3],[sg,pl],[mas,fem,neut]]). | {user consulted, 10 msec 368 bytes} yes | ?- compile_boolean_types. yes | ?- X => ( sg & mas ; ~2 ). X = agr(0,_L,_K,_J,_I,_H,_G,_G,_G,_G,_G,_F,_F,_E,_D,_C,_B,_A,1) ?

The example shows how complex terms are created for such boolean types. This is useful because disjunction and negation can be handled by ordinary uni cation in this way [6]. Luckily the pretty printing routines will turn such complex turns back into something more readible: | ?- X: agr => (sg & mas ; ~2 & neut), latex_fs(fs(X)).

produces: 

cat



agr : 1&neut;sg&mas;3&neut

4.6 The lex string library This library provides the predicate lex string/1. This predicate can be used in the de nition of start hook/4. The argument of lex string/1 is a list of words: the string to be parsed. This library takes care of lexical lookup, and warns if words are unknown. The input string is asserted as a number of clauses for the predicate lex/4 and ign lex/4. In these clauses the arguments respectively are: 35

1. An integer indicating the begin position in the string. 2. An integer indicating the end position in the string. 3. An arbitrary Prolog term indicating the category of the lexical entry. 4. A ground term as a unique identi er of the lexical entry that was used. For this mechanism to work it is assumed that lexical entries are de ned as clauses for the predicate lexicon(Words,Category,RuleName). Note that Words here is a list of words, rather than an atom (to allow for multi word units). The category can be any Prolog term. The RuleName is supposed to be some key that uniquely identi es this lexical entry. The ign lex/4 de nition is similar to the lex/4 de nition, but is based on ign lexicon/3 rather than on lexicon/3. The di erence between the two di erent versions of the lexicon predicate is that the latter one is supposed to subsume the rst one, but does not contain any semantic information. This is useful for parsing strategies in which during a rst phase no semantics is used (e.g. to use packing strategies more succesfully).

4.7 Extended Tk The library xtk provides a few useful extensions to the Tk library de ned by ProTcl. For convenience this library also makes the library(tk) predicates available, so if you use xtk you don't need to include tk. The most interesting predicates de ned by this library are of two kinds. The rst kind allows more exibale evaluation of Tcl/Tk scripts from Prolog: tcl/1 tcl(X) is equivalent to tcl(X,[]), cf. below. tcl/2 The rst and second argument are of the same type as accepted by the Sicstus built-in format/2 predicate. Thus, the rst argument is either an atom or a string and contains escape sequences for which the elements of the second argument can be substituted. The result is evaluated by Tcl/Tk. As an example, the query tcl("canvas ~a ~a ~a",['.c','-bg',white])

results in the evaluation of the Tcl script: canvas .c -bg white

As tcl/2, with the addition that the third argument is instantiated as the return of the Tcl script. E.g.:

tcl/3

?- tcl("set x ~w",[v(t)],Z). Z = 'v(t)' ?

The second kind of extension o ered by library(xtk) facilitates calling Prolog predicates from a Tcl script. To this end the tcl le SP interact.tcl should be sourced. This le de nes the following Tcl procedures: SP prolog SP prolog call (var). call can be an ordinary prolog call, it will be parsed on the Prolog side rst. Furthermore, if the goal succeeds then the procedure returns the instantation of var (occuring in call usually) or `1' if no var is speci ed; otherwise it returns failure. Prolog errors return a tcl error. SP prolog all SP prolog all call var Similar, but in this case `var' must be speci ed. The result will be a Tcl list of the instantiations of var for all solutions of call. Solutions are collected using ` ndall'. 36

4.8 Env The library env provides the predicate getenv/2. The rst argument should be an environment variable (in the form of a Prolog atom). The second argument will be uni ed with the current value of that variable (also as a Prolog atom). Example: | ?- getenv('HOME',X). X = '/users1/vannoord' ?

4.9 Atom length

This library de nes the predicate atom length/2 where the rst argument should be an atom, and the second argument will be uni ed with the length of that atom (i.e. the number of characters).

4.10 Concat This library provides the following predicates to manipulate atoms: concat/3 All of the arguments are atoms. The third argument is the concatenation of the rst and second argument. Can be used in multiple directions, as long as two arguments are instantiated at the time of calling. concat all/3 The rst argument is a ground list of atoms. The second argument will be instantiated to the result of concatenating all of the atoms from this list, separated with the atomic third argument. E.g.: | ?- concat_all([src,'Hdrug2.4','Hdrug','Prolog',library],X,'/'). X = 'src/Hdrug2.4/Hdrug/Prolog/library' ?

concat all/2 . Same as above, assuming the third argument is the empty atom.

37

Chapter 5

Installation 5.1 Where to get it? The package is available from anonymous ftp in directory: ftp://ftp.let.rug.nl/pub/prolog-app/Hdrug/

The newest version can be found as the gzipped tar- le hdrugSUF.tar.gz where SUF is the version number. Alternatively the same le is accessible through World Wide Web: http://www.let.rug.nl/~vannoord/prolog-app/Hdrug/

5.2 What other software do you need? In order to use the full functionality of Hdrug you need the following programs: (apart from the requirement that you have some UNIX machine running the X window system). Package Free? Really neccessary? Sicstus Prolog 2.1.8 (or higher) + Tcl 7.3 / Tk 3.6 (by J. Ousterhout) + + ProTcl 1.1 or higher (by Micha Meier) + + BLT library 1.7 (Tk extension) + -1 TkTree + -2 LATEX and Xdvi + -3 Treemaker (Tex extension) -4 Refer to the appendix ( A) for some information on the programs mentioned in this table. The program has been tested for HP-UX 9000/710 730, Linux (1.0, 1.1,1.2) and Sun. As long as you manage to get ProTcl to work, you should be all set. Note that both on HP-UX and

1 Only for Tk output of viewing the statistics of a comparion of di erent parsers, if you don't have it, you can use an alternative (less pretty) by using the le st tk.pl instead of st blt.pl; cf. Make le.defs include an option to tell the make procedure about this. 2 Parse trees looks much better if you have the TkTree widget. If you don't there is an alternative Tree widget entirely written in standard Tcl/Tk; cf. Make le.defs. Trees of which the nodes are feature structures are only possible using TkTree. Note that TkTree is implemented in C++ which implies some further complications in adding it (essentially this means you need to link in the G++ and GCC libraries explicitly too). 3 Only for LaTeX/Xdvi output. 4 Only for LATEX/Xdvi output of trees. From Univ. of Paderborn, contact [email protected]. It costs around DM 50. Better than other things I've seen, although not ideal (even it can deal with nodes of the tree that vary in their vertical size, you need to have set the nodeskip variable large enough such that the largest node ts inside it. This can be accomplished from Hdrug using the nodeskip ag.

38

Linux I did not manage to get ProTcl to work if I used dynamic loading of the C code. It does however work smoothly if I load the ProTcl C code statically. I have included a directory including some facilities to make the construction of a statically compiled version of SICStus with ProTcl support somewhat easier. For some machines static loading is recommended because dynamic loading is slow.

5.3 How to install? First, of course, determine in which directory you want to unpack the package. Let's assume that you decide to use directory /usr/local/src. In that case, unpack the tar le in this directory. This should give you a directory Hdrug. This directory contains a slightly patched version of protcl 1.4, and a directory containing the actual Hdrug sources.

Installing ProTcl In order to build Hdrug, you rst have to install ProTcl. Chances are that

you need to build a static version of ProTcl. So, you rst follow the instructions in the ProTcl README le. After you construct the tk.o, tkAppInit.o, libinit.a and dirs.pl les, nd out whether you need to build a statically compiled version. The easiest way to nd out whether ProTcl works is to do: % sicstus [-tk]. tk_demo.

If this works, you probably can ignore the Static directory. If not, please edit the Make le.defs in Static and do a `make' followed by a make install. This builds `ProTcl' (in e ect a patched Sicstus) that can be used to build Hdrug. If you include the .o les from the Hdrug library, then you have to compile those rst.

Installing Hdrug The building of the Hdrug system consists of the creation of a number of sub-parts of the system. Each of these parts refers to the same con guration le. This is the le . Therefore, the single most important step of the installation procedure is to edit this le to suite your local setup and your personal preferences. Makefile.defs

5.3.1 Make le.defs

This le contains a number of variable assignments. Refer to this le for an explanation of all the options.

5.3.2 Installing Hdrug and the Hdrug applications

If the con guration le Make le.defs is properly edited, then the next step is to create the Hdrug kernel with a simple application. This is accomplished with the make test option. If everything works this should install the TD command in the directory given by the BINDIR variable in Make le.defs. If you are happy with the way this simple application works, you can then construct all applications. This is accomplished by simply typing make all. Note that if you changed the Make le.defs le in the mean time, you should do a make new in order to be sure that the changes take e ect. Note that the creation of the TA application is very slow the rst time. If this succeeds you will have the commands TA, TC, TD, TG, TL, TT and TX installed in your BINDIR. If you run e.g. the TC command, you will rst cd to the directory in which this application is de ned, and then Hdrug will be started with this application loaded. Note that by default a Sicstus saved-state is generated for each grammar. These saved states are huge (3 Meg is not an exception). If you are short of diskspace you can try: 39





 

in Make le.defs de ne STATE OR SCRIPT to script This entails that no saved states are built, but the application is started by a script. Of course for large grammars there is a severe cost in speed of startup. use the Sicstus built-in mechanism for building compressed saved states. This is done by setting the environment variable SP COMPRESS SAVE to 1. I've found that this is not quite reliable, sometimes such states cannot be restored.. Furthermore, saves less space than the next method. use TCX to compress executables transparantly. I've used TCX on Linux. Note that compression is rather slow. Reliable. Savings up to 75%. (Linux only) use the zlibc C-library replacement. This is what I am currently using on Linux.

Application Defaults

Hdrug always starts by reading the application-defaults le ./Tcl/Hdrug.ad. After that, it searches for a le Hdrug in the standard places (cf. below). If you don't need to change anything, then you don't need to install this le. Otherwise, copy Hdrug.ad to e.g. /usr/lib/X11/app-defaults and edit the le to your taste. Note that Hdrug will expect that the directory in which this application defaults le is installed, is accessible via one of the environment variables XUSERFILESEARCHPATH, XFILESEARCHPATH, XAPPLRESDIR. Also note that Hdrug does not understand conventions in these variable names such as %n. As a consequence you might need to add some paths to one of these variables. Note that Hdrug prints a message to standard output when it reads the application defaults le successfully.

Starting an Hdrug Application

The commands TA, TC, TD, TG, TL, TT and TX optionally take the argument `notk'. This calls the saved-state or the script loading the example grammar, but it does not yet start the menu sytem. Use the predicate x/0 to start the environment from the Sicstus prompt. Note that these options are NOT preceded by the usual dash, as Sicstus does not allow you to (all dashed options are interpreted by Sicstus internally. Is this still true in #9??).

40

Bibliography [1] Gosse Bouma and Gertjan van Noord. Head-driven parsing for lexicalist grammars: Experimental results. In Sixth Conference of the European Chapter of the Association for Computational Linguistics, Utrecht, 1993. [2] Gosse Bouma and Gertjan van Noord. Constraint-based categorial grammar. In 31th Annual Meeting of the Association for Computational Linguistics, New Mexico, 1994. [3] Gosse Bouma and Gertjan van Noord. A lexicalist account of the dutch verb cluster. In Gosse Bouma and Gertjan van Noord, editors, CLIN IV, Papers from the Fourth Clin Meeting, Groningen, 1994. [4] Bob Carpenter. The attribute logic engine user guide. Technical report, Laboratory for Computatonal Linguistics, Carnegie Mellon University, Pittsburgh, 1992. [5] Bob Carpenter. The Logic of Typed Feature Structures. Cambridge University Press, New York, 1992. [6] C.S. Mellish. Implementing systemic classi cation by uni cation. Computational Linguistics, 14(1), 1988. [7] Richard A. O'Keefe. The Craft of Prolog. The MIT Press, 1990. [8] John K. Ousterhout. Tcl and the Tk Toolkit. Addison Wesley, 1994. [9] Fernando C.N. Pereira. Extraposition grammars. Computational Linguistics, 7(4), 1981. [10] Peter Ross. Advanced Prolog. Addison-Wesley, 1989. [11] Stuart M. Shieber, Gertjan van Noord, Robert C. Moore, and Fernando C.N. Pereira. Semantic-head-driven generation. Computational Linguistics, 16(1), 1990. [12] Gertjan van Noord. An overview of head-driven bottom-up generation. In Robert Dale, Chris Mellish, and Michael Zock, editors, Current Research in Natural Language Generation. Academic Press, 1990. [13] Gertjan van Noord. Head corner parsing for tag. Computational Intelligence, 10(4), 1994. [14] Gertjan van Noord and Gosse Bouma. Adjuncts and the processing of lexical rules. In Proceedings of the 15th International Conference on Computational Linguistics (COLING), Kyoto, 1994.

41

Appendix A

Useful addresses Ale Is available from by anonymous ftp from ftp://j.gp.cs.cmu.edu/usr1/carp/ftp/ Address: Bob Carpenter [email protected] Gerald Penn [email protected] Computational Linguistics Program, Philosophy Dept. Carnegie Mellon University, Pittsburgh, PA 15213 Phone: (412) 268-8043 Fax: (412) 268-1440

ProTcl The original is available by anonymous ftp from ftp://ftp.ecrc.de/pub/eclipse/progs Documentation is available from http://www.ecrc.de/eclipse/html/protcl.html ECRC, Arabellastr. 17 D-81925 Munich 81 [email protected], Tel. +49-89-92699-108, Fax +49-89-92699-17

Sicstus Prolog From the Swedish Institute for Computer Science (SICS). Send requests for or-

dering informationto [email protected]. Send bug reports to [email protected]. Documentation is available from http://www.sics.se/ps/sicstus.html Tcl/Tk The Tcl/Tk WWW homepage: http://www.sco.com/IXI/of interest/tcl/Tcl.html The FAQ is also accessible via WWW: http://www.cis.ohio-state.edu/hypertext/faq/usenet/tclfaq/top.html The Tcl/Tk sources are available from ftp://ftp.cs.berkeley.edu/ The single most important ftp-site for Tcl/Tk and extensions ftp://ftp.aud.alcatel.com. This is a list of mirrors: ftp://syd.dit.csiro.au/pub/tk/ ftp://ftp.ibp.fr/pub/tcl/ ftp://src.doc.ic.ac.uk/packages/tcl/tcl-archive/ ftp://ftp.luth.se/pub/unix/tcl/ftp.aud.alcatel.com mirror/ ftp://ftp.switch.ch/mirror/tcl/ ftp://ftp.sterling.com/programming/languages/tcl/ ftp://fpt.sunet.se/pub/lang/tcl/ ftp://ftp.cs.columbia.edu/archives/tcl/ ftp://ftp.uni-paderborn.de/pub/unix/tcl/alcatel/ ftp://ftp.rge.com:/pub/tcl/ 42

Note that a draft of Ousterhout's book is also available electronically as PostScript les. TkTree 3.6.2 This Tcl/Tk extension is also available by anonymous ftp. Note that this extension requires C++ (g++). Allan Brighton Free-lance Software Engineer E-mail: [email protected] (home) or: (until end of March 95) [email protected] (work) Ph: [+49] (0) 8094-1370 Zaissing 3 8019 Steinhoering, Germany (near Munich)

BLT 1.7 The BLT extension is available by anonymous ftp from the standard Tcl/Tk archives

(cf. above). Send bugs reports, correspondence, etc. to [email protected]. LATEX Read the FAQ from the comp.text.tex newsgroup. It is availabe by anonymous ftp ftp://rtfm.mit.edu/pub/usenet/news.answers/tex-faq TreeMaker From Daniel Curatolo, Univ. of Paderborn Germany. Email: [email protected]

43

Suggest Documents