XMG for TAGs and IGs An Example-Based Presentation Joseph Le Roux and Yannick Parmentier June 20, 2007
Introduction ◮ Users always want new features!
Introduction ◮ Users always want new features! ◮ How to add a new type of information to XMG?
Introduction ◮ Users always want new features! ◮ How to add a new type of information to XMG? ◮ It depends on what is to be added:
Introduction ◮ Users always want new features! ◮ How to add a new type of information to XMG? ◮ It depends on what is to be added: ◮ Extending a Data Structure ◮ e.g. polarised features
Introduction ◮ Users always want new features! ◮ How to add a new type of information to XMG? ◮ It depends on what is to be added: ◮ Extending a Data Structure ◮ e.g. polarised features ◮ Extending the Solver ◮ e.g. colours and other principles
Introduction ◮ Users always want new features! ◮ How to add a new type of information to XMG? ◮ It depends on what is to be added: ◮ Extending a Data Structure ◮ e.g. polarised features ◮ Extending the Solver ◮ e.g. colours and other principles ◮ Adding a New Dimension ◮ e.g. semantics, interface
Outline XMG Architecture Overview Core Language Example Extending a Data Structure Definition Changes in the Compiler Changes in the VM Extending the Solver Dynamic solver Example Principles Adding a Dimension Motivation Implemented Dimensions How to Add a New Dimension
Outline XMG Architecture Overview Core Language Example Extending a Data Structure Definition Changes in the Compiler Changes in the VM Extending the Solver Dynamic solver Example Principles Adding a Dimension Motivation Implemented Dimensions How to Add a New Dimension
XMG Architecture XMG software:
XMG Architecture XMG software: Compiler in: a metagrammar (classes, DCG) out: S-Code
XMG Architecture XMG software: Compiler in: a metagrammar (classes, DCG) out: S-Code Virtual Machine in: S-Code out: List of multi-dimensional descriptions
XMG Architecture XMG software: Compiler in: a metagrammar (classes, DCG) out: S-Code Virtual Machine in: S-Code out: List of multi-dimensional descriptions Constraint Solver in: α Description (1-dimension) out: α List
The core language ◮ A language to combine tree fragments: Class Name → Content ::= Content Description | Name | ::= Content ∨ Content | Content ∧ Content
The core language ◮ A language to combine tree fragments: Class Name → Content ::= Content Description | Name | ::= Content ∨ Content | Content ∧ Content ◮ A language to describe tree fragments: x → y | x → + y | x → ∗ y | Description ::= x ≺ y | x ≺ + y | x ≺ ∗ y | x [ f : E ] | x ( p : E ) | x = y
Example X [cat:s] SubjectCan → Z ↓ [cat:n] Y [cat:v] X [cat:s] Active → Y ⋄ [cat:v] Intransitive SubjectCan ∧ Active ( ∗ ) →
Example X [cat:s] SubjectCan → Z ↓ [cat:n] Y [cat:v] X [cat:s] Active → Y ⋄ [cat:v] Intransitive SubjectCan ∧ Active ( ∗ ) → X [cat:s] Intransitive → Z ↓ [cat:n] ⋄ Y [cat:v]
Example X [cat:s] SubjectCan → Z ↓ [cat:n] Y [cat:v] class SubjectCan declare ?X ?Y ?Z { <syn>{ node X [cat=s]; node Y [cat=v]; node Z [cat=n](mark=subst); X -> Y; X -> Z; Z >> Y } }
Outline XMG Architecture Overview Core Language Example Extending a Data Structure Definition Changes in the Compiler Changes in the VM Extending the Solver Dynamic solver Example Principles Adding a Dimension Motivation Implemented Dimensions How to Add a New Dimension
Adding polarised features to XMG ◮ Goal: Generate Interaction Grammars ◮ Syntactic Structures: Polarised Tree Description ◮ We need polarised features:
Adding polarised features to XMG ◮ Goal: Generate Interaction Grammars ◮ Syntactic Structures: Polarised Tree Description ◮ We need polarised features: ◮ x[f:E] ⇒ x[f,pol,E] ◮ pol ∈ { = , + , − , ≈}
Changes in the Compiler This modification consists in: 1. adding new syntactic constructions to the parser for features node N[cat =+ n, funct =- X, gen = Y, num=~ Z]
Changes in the Compiler This modification consists in: 1. adding new syntactic constructions to the parser for features node N[cat =+ n, funct =- X, gen = Y, num=~ Z] 2. checking the AST (features vs. properties)
Changes in the Compiler This modification consists in: 1. adding new syntactic constructions to the parser for features node N[cat =+ n, funct =- X, gen = Y, num=~ Z] 2. checking the AST (features vs. properties) Now, a feature is ( feat , ( val , pol ))
Changes in the VM Engine.unify : unify((val1,pol1),E1,(val2,pol2),E2) ⇒ unify(val1,E1,val2,E2) unify(pol1,E1,pol2,E2)
Changes in the VM Engine.unify : unify((val1,pol1),E1,(val2,pol2),E2) ⇒ unify(val1,E1,val2,E2) unify(pol1,E1,pol2,E2) ◮ Idea: A New Class Polarity with method unify ◮ Objects manage their own unification: no need for a new method in the engine
Changes in the VM Engine.unify : unify((val1,pol1),E1,(val2,pol2),E2) ⇒ unify(val1,E1,val2,E2) unify(pol1,E1,pol2,E2) ◮ Idea: A New Class Polarity with method unify ◮ Objects manage their own unification: no need for a new method in the engine ◮ New Data Structure = New Class + unify
Outline XMG Architecture Overview Core Language Example Extending a Data Structure Definition Changes in the Compiler Changes in the VM Extending the Solver Dynamic solver Example Principles Adding a Dimension Motivation Implemented Dimensions How to Add a New Dimension
Architecture of the TAG Solver ◮ Goal: Constrain admissible structures
Architecture of the TAG Solver ◮ Goal: Constrain admissible structures ◮ Tree Descriptions → Trees
Architecture of the TAG Solver ◮ Goal: Constrain admissible structures ◮ Tree Descriptions → Trees ◮ Syntactic dimension: ◮ Tree Solver: t ◮ Additional Solvers, aka Principles: p 1 , . . . , p n
Architecture of the TAG Solver ◮ Goal: Constrain admissible structures ◮ Tree Descriptions → Trees ◮ Syntactic dimension: ◮ Tree Solver: t ◮ Additional Solvers, aka Principles: p 1 , . . . , p n We build a solver s from t and a selection of p i
The Tree Solver Each node in the input description is associated with an integer. initNodes for each node ( x ) we partition the other nodes: equal, above, below, or on its sides: Up Eq Right Left Down N i node ( Eq : {� ints �} Up : {� ints �} Down : {� ints �} ::= x Left : {� ints �} Right : {� ints �} )
Tree Solver ◮ posCstr The input description is converted into relation constraints on node sets. For instance, the dominance relation x → y can be translated as: x . EqUp ⊆ N j x . Down ⊇ N j y ≡ [ N i y . Up ∧ N i x → N j y . EqDown N i x . Left ⊆ N j x . Right ⊆ N j ∧ N i y . Left ∧ N i y . Right ]
Tree Solver ◮ posCstr The input description is converted into relation constraints on node sets. For instance, the dominance relation x → y can be translated as: x . EqUp ⊆ N j x . Down ⊇ N j y ≡ [ N i y . Up ∧ N i x → N j y . EqDown N i x . Left ⊆ N j x . Right ⊆ N j ∧ N i y . Left ∧ N i y . Right ] x . Down ⊇ N j ◮ N i y . EqDown
Principles This framework can be extended to solve specific constraints. The idea: 1. extension of the node representation (tuple fields), 2. definition of additional constraints on these fields.
Principles: Colour Resource/Need mechanism: semi-automatic Node-merging
Principles: Colour Resource/Need mechanism: semi-automatic Node-merging ◮ Red nodes cannot unify. ◮ Black nodes may unify with white nodes. ◮ White nodes must unify with black nodes
Principles: Colour Resource/Need mechanism: semi-automatic Node-merging ◮ Red nodes cannot unify. ◮ Black nodes may unify with white nodes. ◮ White nodes must unify with black nodes 1. extension of the node representation: we add a field RB 2. definition of additional constraints on these fields: x ∈ Black RB x = x ⇒ x ∈ White RB x ∈ Black ⇒ x ∈ Red RB x = x ∧ Eq x = { x } ⇒ x → y RB x � = RB y ⇒
Principle API ◮ A principle is an object with methods: ◮ args : new solver attributes ◮ init : internal initialisation ◮ initNodes : additional initialisation of the nodes (new fields) ◮ postCstr : additional constraints
Principle API ◮ A principle is an object with methods: ◮ args : new solver attributes ◮ init : internal initialisation ◮ initNodes : additional initialisation of the nodes (new fields) ◮ postCstr : additional constraints ◮ A solver is an object made from several principles, with the same methods.
Principle API ◮ A principle is an object with methods: ◮ args : new solver attributes ◮ init : internal initialisation ◮ initNodes : additional initialisation of the nodes (new fields) ◮ postCstr : additional constraints ◮ A solver is an object made from several principles, with the same methods. ◮ DescriptionSolver : function that applies a strategy to a solver to get solutions. (TAG or IG)
Recommend
More recommend
