Currently, after #88 , the parser supports descriptions like
class Game {
win : Player -> Bool
}
lexicon win -> "{Player} wins {Game}"
Now, we want to support
≥3-place arguments: "{Researcher} spends {Holiday} on {Beach}"
Unexpected part-of-speech or role in a sentence. For instance, instead of inadequate(savings_account), you can have savings_account to be the function, and apply it to inadequate. We then need to allow a description for savings_account : FinancialStatus -> Bool. The argument won't be a NP, but rather the actual predicate.
Until now, we have assumed that the classes are always NPs, and predicates are NPs, APs or VPs. Now even classes can be APs. This is a real example, I couldn't have made it up myself. :-D
The overall problem is where these things happen. Right now we have a RGL-based parsing grammar, where we parse the description. The pieces of the parsed description become then the concrete syntax of our application grammar, which has extremely simple abstract syntax. The abstract syntax is optimised for being easy to manipulate from an external program, and there is nothing linguistically motivated there.
Simplified workflow for one layer of grammars would be this:
We need to add extra steps to accommodate for 2 layers of grammars. I don't know what is the best way to proceed.
Currently, after #88 , the parser supports descriptions like
Now, we want to support
"{Researcher} spends {Holiday} on {Beach}"inadequate(savings_account), you can havesavings_accountto be the function, and apply it toinadequate. We then need to allow a description forsavings_account : FinancialStatus -> Bool. The argument won't be a NP, but rather the actual predicate.Until now, we have assumed that the classes are always NPs, and predicates are NPs, APs or VPs. Now even classes can be APs. This is a real example, I couldn't have made it up myself. :-D
The overall problem is where these things happen. Right now we have a RGL-based parsing grammar, where we parse the description. The pieces of the parsed description become then the concrete syntax of our application grammar, which has extremely simple abstract syntax. The abstract syntax is optimised for being easy to manipulate from an external program, and there is nothing linguistically motivated there.
Simplified workflow for one layer of grammars would be this:
We need to add extra steps to accommodate for 2 layers of grammars. I don't know what is the best way to proceed.