Nonempty Meaning

[nathimel]

Right now Expression has default values for form and meaning, "" and the empty tuple, respectively.

But (at least) because Meaning requires a prior over referents, it expects a nonempty collection of referents. Of course it's easy to include this edge case do avoid div by 0, and maybe return an empty collection for the prior. But in practice, we don't ever consider emtpy meanings in effcomm experiments either.

We've already discussed making GrammaticalExpression not be a subclass of Expression; but highlights more fundamental choices: do we want to require a nonempty Meaning? Then, should we require a form and a meaning in Expression?

I lean towards being more restrictive, and requiring a form and nonempty meaning. But then, this will raise an error in grammar.py: in lines 217 and 272

https://github.com/CLMBRs/ultk/blob/main/src/ultk/language/grammar.py#L217

[shanest]

Great points! Just going to cross-reference issue #30 here for good measure. I think I'm convinced that GE should not be an E now.

One reason we might want to allow for empty meanings in general: e.g. for contradictory expressions like not(subset(A, A)). And that empty meaning would be different from a None for instance. In the indefinites example, I manually removed the empty meaning from the set in generate_expressions, but I could imagine wanting to keep it around.

[nathimel]

Yeah that's how the modals code works too, generate all meanings then remove the empty one. Feels like one might want to keep it around for clerical reasons, but not really to do anything with it. For now, the only error that results is if you try and access the prior for the empty meaning. Options: (1) return an empty collection, or (2) raise an Exception.

[shanest]

I think #43 "solved" this after our discussion. In particular, we allow empty meanings to exist, but dist will raise an error when trying to compute a prior for those, so they won't work well with the informativity calculations.