Spaces and colons in command names

[paulvonhippel]

Some Stata commands, such as svy:, include colons on the command line. And some, such as mi estimate:, also include spaces. When programming your own commands, how do you incorporate colons and spaces into the syntax. I don't see any provision for this in the syntax command.

[Nick Cox]

If you want to allow your command to use a prefix command that is (usually? always?) a hook on the program command.

If you want to write your own, look inside an existing similar command and steal code. More positively put, _on_colon_parse and gettoken are your friends as well as syntax.

A deep general idea that must be documented somewhere but is easy to miss: syntax works on whatever is in local macro 0 -- which by default is whatever you type after a command name, but can be whatever you assign to it.

I have written a few commands based on stuff : more stuff and I don't read the manual entries unless it's unavoidable. I just look at other command files.

[paulvonhippel]

Thanks, Nick Cox . What do you mean by "a hook on the program command"?

[Nick Cox]

The command program has options like [ nclass | rclass | eclass | sclass ] byable(recall[, noheader] | onecall) properties(namelist) sortpreserve plugin]

[paulvonhippel]

Thanks, I see that, but which program option can be used to write a prefix like svy: or mi estimate:? In help program he only mention I see of a prefix or colon is in connection with byable.

[Joro Kolev]

You can read this Stata Tip for minimal example of how prefix commands work:
https://www.elwyndavies.com/stata-ti...s-as-a-prefix/

[daniel klein]

Paul can read all about implementing commands that work with svy and mi estimate in [P] program properties.

In modern versions of Stata (I think since Stata 14), you can also add your own imputation method; see [MI] mi impute usermethod. However, from what I have understood from other threads, Paul wants entirely different machinery (i.e., bootstrap then impute).

Concerning spaces in command names, others have pointed to the right places. Here is a basic layout that I would use

program boot_mi_impute
    version 16
    
    gettoken subcmd 0 : 0
    
    if      ("`subcmd'" == "mlmi") _mlmi `0'
    else if ("`subcmd'" == "foo")  _foo  `0'
    else {
        display as err "subcommand must be one of mlmi or foo"
        exit 198
    }
end

program _mlmi
    ...
end

program _foo
    ...
end

The code above would allow the user to type

boot_mi_impute mlmi ...

or

boot_mi_impute foo ...

where mlmi and foo could be the names for two different (sub-)methods of the (main) method implemented in boot_mi_impute. You could put _miml and _foo into separate ado-files if you wanted to. If you wanted that, I recommend naming the files boot_mi_impute_mlmi and boot_mi_impute_foo so their names reflect that these are subroutines.