I never liked the way greetings worked, and I ended up moving the interlocutor-changing behavior into an activity instead of an action in my Speech Motivations extension.
I think you can do everything you need to do without DO. I’m looking at some possibilities…
I found a hack that could help you, but it’s slow - it doesn’t rely on your caching scheme:
[code]
Test is a room. Bob is a man in test. Sue is a woman in Test.
There is a table in Test. There is a chair in Test.
Discussability relates various things to various people. The verb to be discussable with implies the discussability relation.
The table is discussable with Bob. The chair is discussable with Sue.
Engaging it about is an action applying to one thing and one visible thing.
To decide what object is the parser’s returned noun: (- parser_results–>INP1_PRES -).
Definition: A thing (called the subject matter) is relevant:
if the parser’s returned noun is not a person, no;
decide on whether or not the subject matter is discussable with the parser’s returned noun.
Understand “talk to [someone] about [any relevant thing]” as engaging it about.
Report engaging someone about something:
say “You talk to [the noun] about [the second noun].”
Test me with “talk to bob about table/talk to bob about chair/talk to sue about table/talk to sue about chair”[/code]
The “parser’s returned noun” is stolen out of Ron Newcomb’s Original Parser. You can’t use “the noun” here because when the second noun is being parsed, it actually sets the noun to the object that is being tested.
Alternatively, you could do your caching at the point where the noun is determined. This hack uses side effects to mark what is being parsed. I haven’t checked whether this would be faster or not:
[code]Test is a room. Bob is a man in test. Sue is a woman in Test.
There is a table in Test. There is a chair in Test.
Discussability relates various things to various people. The verb to be discussable with implies the discussability relation.
The table is discussable with Bob. The chair is discussable with Sue.
Engaging it about is an action applying to one thing and one visible thing.
The interlocutor-to-be is an object that varies.
A thing can be flagged-ready or flagged-unready.
Definition: a person is being parsed as the interlocutor:
if it is the interlocutor-to-be, yes;
Now the interlocutor-to-be is it;
Now every thing is flagged-unready;
Now every thing that is discussable with the interlocutor-to-be is flagged-ready;
yes.
Understand “talk to [someone being parsed as the interlocutor] about [any flagged-ready thing]” as engaging it about.
Report engaging someone about something:
say “You talk to [the noun] about [the second noun].”
Test me with “talk to bob about table/talk to bob about chair/talk to sue about table/talk to sue about chair”[/code]
In both of these cases, you would need to write a rule for handling the “noun does not make sense in that context” error for the case where the second noun can’t be discussed with the noun. Or write an mistake action that takes text instead of the second noun.
I haven’t worked through the logic or code here yet, but do you really need both these actions? It looks like you always want subjectifying when the second noun isn’t the current interlocutor, and you always want discussing when the second noun is the current interlocutor, so why not just make one overall action that redirects to the appropriate behavior depending on whether the second noun is the current interlocutor?
For the other code, I was thinking that non-available quips could be blocked at the action stage, but if you’ve got something that gives the desired behavior without relying on all that machinery it’s probably much better. [size=85]But I’m still really proud of having found a way to make it work as well as it did.[/size]
Well, the difference was (and thanks for making me realize I had overlooked this!) the noun in subjectifying is a subject, while the noun in discussing is a quip. Commands valid for the former are a subset of those valid for the latter, because a quip can be referred to by a subject.
Yes, that’s the parsing code: the understand lines provide this availability checking, by only recognizing “any flagged-ready quips”, and so on. The problem is, the use of “any” here leads to the dreaded “context” error whenever this checking breaks down.
Hmm, I wonder if instead, I should just place valid quips into scope while discussing, or maybe use the container-within-an-everywhere-accessible-backdrop method from WI Ex 201, Puff of Orange Smoke…