sintrastes / montague Goto Github PK

It would probably be better to just encode these as terms of another type.

Currently there is no semantic validation done in the schema file parsing. This leads to exceptions at runtime, which is not ideal.

There are a lot of different approaches to categorial grammar, and not necessarily a fixed set of connectives or rules.

To allow for experimentation with different approaches, we should make Montague as extensible as possible, potentially using an approach like tagless final encodings.

For instance, we could allow for both non-associative (and as an extension) associative connectives as an extension.

bussproofs.sty looks like it'd be a fairly straightforward way to do this.

bussproofs.sty

We are currently outputting unicode for this, but it would probably be pretty simple to output LaTeX syntax instead.

This would be especially nice in jupyter notebooks, though I am not sure how that integration would work.

In actual Montague semantics, a common feature is the presence of lambda binders. We should add this to our Term type, together with other common logical connectives like "and", "or", and so on.

I'm not entirely sure what the applications of this would be, but this would be interesting to implement to allow for some experimentation.

One idea might be to respond to queries like "What can you tell me about X?", and if we have an approach to generating "interesting" facts (in logical form), then we'd be able to respond to the user in natural language form.

It would be interesting to see if there are any interesting approaches to posing questions back to the user with this approach that would be easier to do in structured form.

This will be useful for frontends like montague-reflex, where we may want to display docstrings as part of the UI for viewing entities and types.

In addition to lambda binders, we should also introduce constructors for existential and universal quantification to allow for the proper treatment of quantifiers.

Currently, characters like | and = are not the easiest to type on a mobile device.

We should consider allowing alternatives such as or for |, and is for =.

Currently, something like adjective = noun -> noun is hard to specify in a schema file. Typealiases would help with this.

Whereas originally what I had in mind for Montague was something that could be fed into a logic programing-like solver, now it is clear that there are at least other possibilities (see the work in Montague.Experimental.Typed and related modules).

I should add some documentation outlining these different approaches, as I think they would be good examples of different potential uses for Montague.

This is necessary for implementing some of the montague-reflex features that allow the user to modify a schema via a UI.

Currently, types like noun | adjective which could belong to multiple possible types are not supported in the schema specification.

As I experiment with this library going forward, it would be nice to keep all of my experiments in one place. For this reason, I want to create an "Montague.Experimental" parent module which will contain multiple submodules for each of these experiments.

See here for some different types of morphology. We'll probably start by some simple examples (such as suffixes) in English, and go on to add other examples.

This presents some interesting computational challenges, as we will need to find a way of translating from raw words to their morphological interpretations. Perhaps (at least for suffixes) a trie-like data structure might be useful for this purpose.