Different extension modules

[inariksit]

What's the relation between gf-rgl/Extend.gf and gf-wordnet/ParseExtend.gf?

1. ParseExtend extends Extend, except for a few excluded functions, e.g. ProDrop, AdvIsNPAP.
2. Some functions that are excluded from Extend, are redefined in ParseExtend with a more general type signature, e.g. InOrderToVP : Ant -> Pol -> Pron -> VP -> Adv, compared to only VP -> Adv in Extend.
3. Some functions are defined only in ParseExtend, e.g. FocusComp : Comp -> NP -> Cl for copula clauses where the complement is shifted to the front, e.g. so am I.

Category 3

I suggest we move category 3. to Extend. Since ParseExtend extends Extend, they would still be accessible for ParseExtend, so no existing grammars break.

Category 2

As for category 2, I see the following options:

• No change: old type signatures in Extend, new type signatures in ParseExtend. If user wants to use the functions with the new type signatures, they need to import ParseExtend.

• Add the ParseExtend versions into Extend with a new name. Thus Extend.gf would have

  InOrderToVP : VP -> Adv ;
  InOrderToVPgen :  Ant -> Pol -> Pron -> VP  -> Adv ; -- TODO better name

  If we do this, then I suggest that we define ParseExtend.InOrderToVP as Extend.InOrderToVPgen, so that there is no duplicate code.

(Third alternative, which I don't suggest, is to update the type signatures in Extend, so that InOrderToVP : VP -> Adv disappears and is replaced by InOrderToVP : Ant -> Pol -> Pron -> VP -> Adv. Downside is that this could break existing code.)

Comments

If you have other points of view or if I've missed something, let me know. Especially @krangelov who has written ParseExtend.

I can move the functions myself, if people are in favour of the move.

[krangelov]

Hi, The short answer is that ParseExtend contains extensions that I found are needed but I didn't want to change the Extend module until I am sure what is the right thing. For instance I don't know how well these extensions generalize to other languages. If you feel like doing it, go ahead and move FocusComp. I don't remember why ProDrop is not imported probably because it is not used in the languages that I worked with. For AdvIsNPAP, I don't even remember what it does. For InOrderToVP it is probably best to leave it in ParseExtend for now, although I would prefer to completely merge Extend and ParseExtend at some point. If you are going to work on some other languages, I would appreciate it if I can get feedback about how much the extensions make sense for the new languages. Then maybe we can consider merging everything to Extend.gf.

…

On Mon, 6 Jul 2020 at 14:25, Inari Listenmaa ***@***.***> wrote: What's the relation between gf-rgl/Extend.gf <https://github.com/GrammaticalFramework/gf-rgl/blob/master/src/abstract/Extend.gf> and gf-wordnet/ParseExtend.gf <https://github.com/GrammaticalFramework/gf-wordnet/blob/master/ParseExtend.gf> ? 1. ParseExtend extends Extend, except for a few excluded functions, e.g. ProDrop, AdvIsNPAP. 2. Some functions that are excluded from Extend, are redefined in ParseExtend with a more general type signature, e.g. InOrderToVP : Ant -> Pol -> Pron -> VP -> Adv, compared to only VP -> Adv in Extend. 3. Some functions are defined only in ParseExtend, e.g. FocusComp : Comp -> NP -> Cl for copula clauses where the complement is shifted to the front, e.g. *so am I*. Category 3 I suggest we *move category 3. to Extend*. Since ParseExtend extends Extend, they would still be accessible for ParseExtend, so no existing grammars break. Category 2 As for category 2, I see the following options: - No change: old type signatures in Extend, new type signatures in ParseExtend. If user wants to use the functions with the new type signatures, they need to import ParseExtend. - Add the ParseExtend versions into Extend with a new name. Thus Extend.gf would have InOrderToVP : VP -> Adv ;InOrderToVPgen : Ant -> Pol -> Pron -> VP -> Adv ; -- TODO better name If we do this, then I suggest that we define ParseExtend.InOrderToVP as Extend.InOrderToVPgen, so that there is no duplicate code. (Third alternative, which I don't suggest, is to update the type signatures in Extend, so that InOrderToVP : VP -> Adv disappears and is replaced by InOrderToVP : Ant -> Pol -> Pron -> VP -> Adv. Downside is that this could break existing code.) Comments If you have other points of view or if I've missed something, let me know. Especially @krangelov <https://github.com/krangelov> who has written ParseExtend. I can move the functions myself, if people are in favour of the move. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#347>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEYFSZBTTT3DDKCBNRXZL43R2G7FNANCNFSM4ORRXMTA> .

[inariksit]

Alright, I see! I'll probably need a bunch of new extensions, and I was planning to add them directly to Extend. I'll have a more concrete idea in some weeks or months from now, just wanted to see the landscape of GF extension modules. I'll let you know if we use other languages than English (that's my intention, but it depends on other things too.) It would make sense to merge the modules as a longer-term goal.