Following is a write up of the Blocks World Extra Credit task.
A blocks world with cones would require the addition of new predicates like cone(c1). Each of these cones would would be treated the same as every other block, except in the case of stacking. When the reference is resolved to be a cone, perform_act will have to have a condition that prints an error when it finds anything being moved "on" a cone. Otherwise, the cone will follow any other motions the same way the blocks are handled.
A left and right ordering would require the State to have additional predicates (or separate State into a stacking state and ordering state) with predictes like left(b2, c1), in which b2 is left of c1. The state can be searched when order is required by resolve_ref like so:
color(Block1, Adjective), member(left(Block1, Block2), OrderState).This would find blocks of a specific color left of a specific block and be able to resolve based on location rather than just stacking context or literal description. "Left" and "right" would need to be added to the natural language parser, as well as new phrases like:
order_phrase(OP(NP, PP, O, Det, PP, NP)) --> np(NP), prep_phrase(PP), det(DET), order(O), prep_phrase(PP), np(NP).
order(o(left)) --> [left]. order(o(right)) --> [right].
prep(p(to)) --> [to]. prep(p(of)) --> [of].
Assuming you wanted the only way to refer to location to be "[some block] to the right/left of [some block]", this would work consistently.
Asking hypothetical questions would require the natural language parser to have new phrases which, when encountered, would dictate the programs next actions. A new perform_act would be added and it's first step would be extracting the first verb, like the other perform_act predicates. It would check if it's one of a set of verbs used in asking questions (ie. "can" or "will") and then follow similarly to the other perform_act predicates, by resolving the references and validating the actions involved. Instead of the last line being perform(...), it would just write "Yes, this action is valid," because if this action had been asked of it, it would have succeeded. A second perform_act beneath it would be required to catch the error case and would just write "No, this action is not valid," and then ask for more input.