Command chaining is something really interesting. Back 4 or 5 years when the ideas of natural language interfaces were popping up, there was the service called YubNub (http://www.yubnub.org, still exists) and it was really simple but worked really well. It's hard to image up front all the new possibilities of chaining brings, but when pieces starts tying together it gets interesting. When they implemented both named parameters and command chaining, lots of commands and meta-commands appeared (like ifThenElse) that made it almost a pseudo-script language for the web. However, their approach and goals were quite different (natural language was not the final goal), so I don't think that everything applies to Ubiquity, but I just wanted to mention it to bring some inspiration.

One idea for how the chaining could work is: when the user types a composite command (let's simplify it by being detected as the word "and" directly followed by a noun verb), only the first command would be interpreted, the second part would be left ignored. On the matches list (where you do the nice underlining of noun-types and such) the second command would be displayed grayed out. When the user is certain that the first command previewed is correct, then pressing Enter or the right arrow key would execute the command, get the lookup data, and move to the next command in the chain. Or perhaps it wouldn't execute the command but just let the user adjust the second command and use a placeholder for the output (similar to the "this" placeholder… could be a nice little box saying "output").

This is all pretty much English only I think (though it would work for portuguese), but I guess the model would break in other languages so I'm excited to see what you'll say about the international challenges about this.

Another thing is that there are some possible action commands that would be chainable, or at least considering that some action commands would have output data. For example, a file uploader command: "upload picture to flickr and e-mail it to mitcho" Of course this is just crazy future imagination

I believe what you're describing in your last paragraph is the a posteriori approach (noun type detection after getting the chainable output of the first verb) I described above.

Nice casual use of "wugs," btw.

I believe what you're describing in your last paragraph is the a posteriori approach (noun type detection after getting the chainable output of the first verb) I described above.

Nice casual use of "wugs," btw.

This would allow chaining of less than fully compatible commands. Take the following example: “get the number of wugs and then multiply by 2” Imagine “multiply” is expecting a number as input, but “get the number of” returns a string like “There are 5 wugs”. But by calling the noun_type_text member of “multiply“‘s input function dictionary, you can recover the number.

This would be bad for intelligent verb suggestion, of course, because presumably any command is going to make an effort to do something with arbitrary text (and most command output can be down-converted to text). I guess you’d have to allow commands to specify a “preferredness” value for each noun type they accept. So a command that accepts email addresses would be a good match for a command that outputs email addresses; a mediocre match for a command that outputs text (because presumably it has some way of fishing an email address out of a larger string); and a poor match for a command that outputs numbers (because no number —> email address conversion is defined)

A further thought: If you impose some API requirements on validation/conversion functions, you can get some extra mileage. First, argument validation functions must not do anything side effectful, but only validate. Second, they must signal some kind of error when validation fails. Then you can run them in the background after the first command is entered. So to return to the above example, if the user types “get the number of wugs and then” and pauses typing, Ubiquity can use the idle time to call commands’ validation functions. The function for validating text input to “multiply” will result in success, because there is a number in “There are 5 wugs.” A function for validating email addresses will fail, though, because there aren’t any email addresses. Then Ubiquity could cull email-address-accepting functions from the list of suggestions.

I think almost every output value will be either generic text, or a URL. Certainly, all commands that open pages could be pretty trivially modified to return those URLs, perhaps wrapped as some kind of URL object with type info, which can easily be consumed as input by one of the arguments of another command. And commands that either set the text selection, or display text output in a transparent message, or put text into the clipboard, could all be changed to output that text as the return value of execute().

A thought: Perhaps instead of the command.execute() explicitly calling openURL, or setTextSelection, the command.execute() should simply return a URL object or a text object. If there's a next command in the chain, it will get that value; if there is not a next command on the chain, then the Ubiquity core will catch it and perform the "default action" based on the data type. The default action would be to set the text selection in the case of text, or to open a URL in the case of a URL.

I have been assuming before that any command which wants to allow chaining would have to specify the nountype of its output. Your alternative (running nountype detection on the output values) is intriguing as it has a lot of flexibility advantages, but it occurs to me that in a lot of cases we may not have any output to run nountype detection on until after the command is executed, at which point it's too late to chain it with anything.