As a search of the Tcl wiki shows, attempts to add named-argument capability to the Tcl proc command have been around for several years.
My own nxproc extension is more comprehensive. (See wiki [0].)
The extension enables named arguments, regular positional arguments, and 'rest' arguments, nxargs and nxunknown. Nxproc also provides (optional) type-checking of procedure arguments. (Types: string, number, bool and enumerated. Enums are lists of values restricting what the arg can contain.)
Nxproc supports TclOO with nxcontructor and nxmethod commands -- same feature set as "plain" nxproc. Also provides case-insensitive '-ci' variants, and runtime display of named-argument default/actual values and types.
Nxproc is a Tcl C extension. Bundle has Windows, Linux binaries. Compiles easily on other platforms.
The OpenACS web server toolkit has a lot of useful Tcl utilities, including the ad_proc procedure, which wraps proc and allows adding of switches, inline docs, and more.
I think it would be very useful to turn ad_proc into a built-in command and incorporate it into TCL.
Personally I'm a fan of TEPAM from tcllib, which does much the same (and tcllib is available through many OS's package managers making it more readily available)
For incorporating into Tcl I'd prefer something simpler that would also work with existing procs. Building on {*}, maybe {@} could work (to skip over arguments to a specified argument}. e.g. when calling a function:
someFunc someVal anotherVal {@}someArgName yetAnotherVal
I implemented something very similar a while ago, it's indeed too bad it's not built-in. I don't think you need such a "quasiquote" function, [list {*}$args] can escape a single command, and then it's a matter of joining multiple commands using a newline. IIRC that's how I did it.
I also had further fun with wrapping "proc" by implementing a "pyproc" which called out to Python while looking like a normal Tcl proc.
The problem is mainly the square brackets that force one to go through strings, in my experience. Can't build something like "set foo [cmd $bar]" purely by using [list ...] shenanigans, since list will quote stuff you don't want quoted.
True, I believe I mostly worked around that limitation by splitting off quoted from unquoted code into separate commands. So in your example "[cmd $bar]" would be in a separate unquoted command, probably putting it in a temporary variable, which can cause problems as it's hard to have a private scope when doing metaprogramming. You can also use "[list]" in the middle of code, but it gets more error prone, for example "set foo \[[list cmd \$bar]\]"
For sure there is a lack of proper "code as data" constructs in Tcl, like you would find in Lisp.
Well... Yes and no. It's definitely better than most shells, but that's a very low bar. It's pretty awful compared to any "real" programming language, which is a problem because it's used in places where a real programming language would be much more appropriate.
Tcl does appear to be a command language done right, I don't think there is a better one. As it was designed after bash etc, I guess the Tcl developers could see the inconsistencies there, which helped them do Tcl right.
As a search of the Tcl wiki shows, attempts to add named-argument capability to the Tcl proc command have been around for several years.
My own nxproc extension is more comprehensive. (See wiki [0].)
The extension enables named arguments, regular positional arguments, and 'rest' arguments, nxargs and nxunknown. Nxproc also provides (optional) type-checking of procedure arguments. (Types: string, number, bool and enumerated. Enums are lists of values restricting what the arg can contain.)
Nxproc supports TclOO with nxcontructor and nxmethod commands -- same feature set as "plain" nxproc. Also provides case-insensitive '-ci' variants, and runtime display of named-argument default/actual values and types.
Nxproc is a Tcl C extension. Bundle has Windows, Linux binaries. Compiles easily on other platforms.
[0] https://wiki.tcl-lang.org/page/nxproc
That looks very nice!
The OpenACS web server toolkit has a lot of useful Tcl utilities, including the ad_proc procedure, which wraps proc and allows adding of switches, inline docs, and more.
I think it would be very useful to turn ad_proc into a built-in command and incorporate it into TCL.
https://nstcl.sourceforge.net/docs/nstcl-core/ad_proc.html
Personally I'm a fan of TEPAM from tcllib, which does much the same (and tcllib is available through many OS's package managers making it more readily available)
https://core.tcl-lang.org/tcllib/doc/trunk/embedded/md/tclli...
For incorporating into Tcl I'd prefer something simpler that would also work with existing procs. Building on {*}, maybe {@} could work (to skip over arguments to a specified argument}. e.g. when calling a function: someFunc someVal anotherVal {@}someArgName yetAnotherVal
I implemented something very similar a while ago, it's indeed too bad it's not built-in. I don't think you need such a "quasiquote" function, [list {*}$args] can escape a single command, and then it's a matter of joining multiple commands using a newline. IIRC that's how I did it.
I also had further fun with wrapping "proc" by implementing a "pyproc" which called out to Python while looking like a normal Tcl proc.
The problem is mainly the square brackets that force one to go through strings, in my experience. Can't build something like "set foo [cmd $bar]" purely by using [list ...] shenanigans, since list will quote stuff you don't want quoted.
True, I believe I mostly worked around that limitation by splitting off quoted from unquoted code into separate commands. So in your example "[cmd $bar]" would be in a separate unquoted command, probably putting it in a temporary variable, which can cause problems as it's hard to have a private scope when doing metaprogramming. You can also use "[list]" in the middle of code, but it gets more error prone, for example "set foo \[[list cmd \$bar]\]"
For sure there is a lack of proper "code as data" constructs in Tcl, like you would find in Lisp.
Actually, you can see the "backslash hell" version here if you want to estimate the clarity gains: https://git.sr.ht/~q3cpma/tcl-misc/tree/f613898c3dcfa3ca958a...
Synopsys tools (either CosmosScope or Custom Wave view) do it by the way of names following values. Like:
Tcl is the shell done right. Simple, logical, consistent.
Well... Yes and no. It's definitely better than most shells, but that's a very low bar. It's pretty awful compared to any "real" programming language, which is a problem because it's used in places where a real programming language would be much more appropriate.
Tcl does appear to be a command language done right, I don't think there is a better one. As it was designed after bash etc, I guess the Tcl developers could see the inconsistencies there, which helped them do Tcl right.
Well, it's certainly much better, especially now that we have dicts to replace arrays. But the specter of https://wiki.tcl-lang.org/page/exec+ampersand+problem (cf https://core.tcl-lang.org/tips/doc/trunk/tip/424.md) still looms.