DKF: Proposed new feature for Tcl. [See fossil branch dkf-command-type]

info type commandName

Returns a string describing the “type” of the command called commandName. For procedures, it returns proc, for native commands, native, for aliases, alias. There's a few others too. Does not dig deep into the complexities of what the command is, but does provide you with enough information to figure out what sort of introspection to use next.

rmax: Maybe the command should be called [info commandtype] (or [info cmdtype] for short), to avoid confusion with other meanings of "type" (e.g. in the sense of typed variables).

---

RFox - 2013-07-10 18:10:53

+1 for rmax's suggestion.

---

dkf - 2013-07-11 08:49:11

Seems reasonable; this is why it's still on a branch!

---

escargo - 2013-07-12

This seems like it ought to work in conjunction with [info commands]. So, are there more things that would be valid inputs to [info commandtype] than are returned by [info commands]? I would also like to see some examples of all the returned values and each of the introspection commands that would be used next. (This might point out where introspection is not implemented deeply enough.)

If "command-like" names are the valid inputs, does that mean that [info commandtype] can return "method" if the name is a method name?

---

dkf - 2013-07-14 14:39:34

But methods are not commands. There is nothing that bridges between the two. (There already is an introspector for method types; has been for a while now.) What this command does is tell you about what sort of command you've got, nothing more, nothing less.

Don't be confused by the name. I'm going to change that once I have better network connectivity...

---

escargo - 2013-07-14

Here we get into the thicket of implementation and introspection. Don't you invoke methods the same way you invoke commands?

If you have something ("commandName") that you can invoke like a command, how do you tell what it is? (Or perhaps, how do you tell how it is implemented?) If you want to be able to resolve details of the implementation of any command-like string argument, then you should be able to handle any inputs reasonably. If your "command invocation" is really a "method invocation," does that mean you should first check to see if your "commandName" is really a method name first? Then, if it is not a method, then use [info commandtype] to see what it is?

---

dkf - 2013-07-16 14:09:51

Now you're just confusing things. If foo is a command name, then it names a command and the one thing you can definitively do with a command is run it by evaluating it:

foo

That might give you an error message, but it works. info cmdtype will give you another, and that will respond with proc or native or … TclOO object handles will respond to this too (they're commands, after all). However, TclOO methods are not commands at all. (Formally, they've got a different C signature and reside in different hash tables.) Using info cmdtype on them will likely result in an error message (to the effect of “can't find that command”).

---

escargo - 2013-07-16

This gets back to one of my earlier questions that was not answered. Are the expected inputs to info cmdtype only the outputs from running [info commands]? If yes, then never mind what I said about methods and method names. If no, then where else would the strings that are legitimate inputs to info cmdtype come from?

---

dkf - 2013-07-17 09:40:36

The items returned by info commands would be a valid source. As would typing in info into a text editor and just using that string. If it's not resolvable to a command, you get an error; it says “command name”, not “anything”, so you should expect validation of that.

Think of it like this: suppose you have a string which might have the name of a procedure in it, and want to get the body of procedure. You would use info body. If the string wasn't a command name, you'd get an error. If it was the name of a command that wasn't a procedure, you'd get an error. Now, with info cmdname you've got a strictly wider set of inputs — all command names, not just procedure names — and the nature of the result is different (natch!) but the same principle applies. Feed in a valid input, get a defined output. Feed in an invalid input, get an error. That's how Tcl works.

---