Using GF grammars with dependent types in external programs

[Belal]

  Hello,

I've read Inari's blog posts on dependent types and embedded grammars and am excited about the prospects of creating applications that can recognize not only grammatically correct sentences but also meaningful ones. 

https://inariksit.github.io/gf/2018/12/28/dependent-types.html

https://inariksit.github.io/gf/2019/12/12/embedding-grammars.html

But I also read that dependent types are not fully implemented in the C runtime:

https://www.grammaticalframework.org/doc/runtime-api.html#python

Type Checking Abstract Trees

The runtime type checker can do type checking and type inference for simple types. Dependent types are still not fully implemented in the current runtime. 

and these threads:

https://groups.google.com/g/gf-dev/c/8HkK7mYg9Gs/m/DdurKNXdAgAJ

https://groups.google.com/g/gf-dev/c/kzgrMDo_Lfc/m/12npFEbzHz4J

https://groups.google.com/g/gf-dev/c/ip6NqidbEo0/m/YXYAEmZx95IJ

Considering the above, what is the recommended approach to using GF grammars with dependent types in external applications (e.g. in Python) in order to parse sentences that are both grammatical and meaningful? Or, phrased differently, is it currently possible to build a GF grammar that can both rule out meaningless constructs and be embedded in external applications given the limitations above? Thank you.

- Belal

[Giuliano Lancioni]

This is a very reasonable approach by Michal Měchura: a plausibility filter encoded in another grammar, which yields plausibility judgments.

https://github.com/michmech/plausibility

The docs describe the approach most clearly. This is fully compatible with the C runtime and aptly separates semantic plausibility from theoretical semantic possibility.

Best,

Giuliano

--

---
You received this message because you are subscribed to the Google Groups "Grammatical Framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gf-dev+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gf-dev/6ab61460-cf2d-4e90-a1ef-67ed4777f2abn%40googlegroups.com.

[Belal]

Thank you Giuliano for sharing this! 

In contemplating the practicality of this approach, I wonder if it can offer more precise feedback as to where the implausibility first occurred?  Since the computed plausibility/implausibility value is being propagated up the tree and we only see it once the string has been fully parsed, is it possible to determine which step in the tree construction process first introduced the implausibility? 

For applications that require giving the user feedback (e.g. second language learning systems that offer the learner hints for semantic, spelling, and grammatical errors or poor word choice, etc.), a plausibility filter will only tell you whether the meaning is non-sensical or not but not why it is so. In such applications, it would be helpful to highlight the problematic input chunks/fragments and offer targeted/relevant feedback. Are there ways to utilize this approach to provide more detailed feedback to the user in an embedded application? Thank you.

- Belal  

[Giuliano Lancioni]

Dear Belal,

I think you can obtain a plausibility judgment for every syntactic chunk in this model, since judgments are present in every rule and are applied in a bottom-up fashion.

Yet I don't think you have a way to detect where in the derivation the judgment became negative.

If you wish a more straightforward way to include semantic judgments in rules (i.e., directly in the abstract component) without using dependent types, and therefore allowing you to use that in the C runtime, In an older post here Krasimir Angelov showed a way you can mimic the behaviour of dependent types through the use of intermediate types. I tried it and it works just fine (although Krasimir himself defines it "unsatisfactory");

https://groups.google.com/g/gf-dev/c/ip6NqidbEo0/m/1m7B5pe581oJ

The strategy here is to create intermediate (Human_LivingForm, Animal_LivingForm) types:

Jean : Human
Marie : Human
Snoopy : Animal

Human_LivingForm : Human -> LivingForm;

Animal_LivingForm : Animal -> LivingForm;

F : LivingForm -> Sentence;

The solution is much more straightfoward (intermediate types can even be created programmaticaly in Python or another language), but I feel the more complex plausibility approach can grasp it better the nuanced nature of semantic restrictions.

Hope this helps,

Giuliano

To view this discussion on the web visit https://groups.google.com/d/msgid/gf-dev/ffcb1585-85b5-401a-b4da-aad11a1bca91n%40googlegroups.com.