You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
Currently, after #88 , the parser supports descriptions like
Now, we want to support
"{Researcher} spends {Holiday} on {Beach}"
inadequate(savings_account)
, you can havesavings_account
to 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.
The text was updated successfully, but these errors were encountered: