Erm... As we're on the subject of over-riding things..

command <look #@object; look at #@object#>

Doesn't work, while:

command <look at #@object#; look #@object#>

Does..

Any reason?

What I mean by "doesn't work" is that, when typing "look at ball", I was getting it coming back with the standard "I can't find that object here", instead of a blank/response.

There's a hash - # - missing in the first one. Would that make a difference?

Oops, sorry..
That's a typo - and not a direct copy/paste.

I've got it. What #@...# really does is:

1) Try to match the whole command, storing the #...# as a string.
2) If it matches, then try to disambiguate the stored string.
2a) If it can disambiguate, run the command.
2b) If it can't disambiguate, give an error and fail.
3) If it doesn't match, go to next command.

So when you do "look at #@object#", "look #@object#", with command "look mirror", it will:
- try to match "look mirror" to "look at #object#"
- Since it can't match, it goes on to the next phrasing
- try to match "look mirror" to "look #object#", and succeeds with #object# == "mirror"
- try to disambiguate "mirror", succeeds.


But when you do "look #@object#", "look at #@object#"
If you try "look at mirror":
- match "look at mirror" against "look #object#", succeeds with #object# == "at mirror"
- try to disambiguate "at mirror" fails
- Since the disambiguation failed, it doesn't try any further commands.

No..

#@object# simply searches for objects in the current room (or in your inventory). If they have alias's then they put the object's real name in the string.. If not - then the real name goes in the string.
If the object isn't found, then a false is returned and the command isn't run.

.. You may be correct in the way it tries to match the command typed against the commands listed..

Nope, if it can match the command to variables, it will either successfully disambiguate or abort.

For example, try creating a room with obj_john_smith (alias "John Smith", alts "John" and "Smith") and obj_frank (alias "Frank"). Create a verb "show #@object1# #@object2#", which does "msg <You show '#object2#' to '#object1#'>".

First, try "show Frank John Smith". It works as expected.
Then, try "show John Smith Frank". It won't work. (If you put in a "John Doe" object in the room and retry, then it will prompt for disambiguation and then abort.)

What happens is, in each case, it will set #object1# and #object2# to the appropriate subphrases, matching each string non-greedily.
(First try, #object1# == "Frank", #obect2# == "John Smith". Second try, #object1# == "John", #object2# == "Smith Frank")
Then, after having matched each phrase to the string, it will attempt to disambiguate the objects.
(First try, it manages to succeed. Second try, it fails.)

Disambiguation occurs when there is more than one object with the same name/alt/alias.
Disambiguation does NOT occur when there is only one object referred to.

I am not disagree'ing with how the parser works - taking what you type literally (eg command <do[space]#string#[space]#string2#>).

I also don't think it stores the #object# and then tries to get the object name.
I'd basically go down the list, then split the string according to the command, and then try to resolve the object names.. More logical than splitting, finding the command, then analysing each string - overwriting themselves.

My wording was careless. I used "disambiguation" to refer to any call to "$getobjectname(...)$", whether it prompted the player for a choice or not. And whether the behavior I described is logical or not, it is the way Quest appears to work.

It is always good practice to list commands long to short:

command <look at #@object#;look #@object#>

When the command "look at ball" is entered but the command code is arranged short to long:

command <look #@object#;look at #@object#>

...then Quest uses the first command "look #@object#" and interprets the object as "at ball" and of course cannot find such an object.