AMG: This page is of historical interest only. The argument expansion syntax has been decided to be {*} immediately followed by the word to be expanded, with no intervening whitespace.
Background
After much discussion around TIP #103 Argument Expansion Command [L1 ] the TIP author, Peter Spjuth, made two polls on the tcl-core mailing list. This was in April/May 2003.
Below is the questions and a summary of the answers received.
The result from the poll lead to the creation of TIP #144 Argument Expansion Syntax [L2 ]
Argument Expansion Poll
1. Should we aim for a global syntax for argument expansion in Tcl 9?
- 10 answers : Yes.
- 1 answer : Maybe. Depends on what the Dodekalogue looks like.
2. Should we aim for an expand command for argument expansion in Tcl 8.5?
- 3 answers : Yes.
- 2 answers : No. It is too big a deal and should go in a major rev.
- Yes, but only if it is compatible with the same solution that will be used in Tcl 9. The only difference should be that in Tcl 9 the expansion is recognized anywhere, while in 8.5 it is limited to the direct args of an "expand" command.
3. If yes on any of the above, should it be based on the backtick (`)? Some other syntax?
- ` is good, almost anything is acceptable including {}
- I think I can live with backquote, but I'm much more comfortable with {}
- ` No, other Yes
- No, I prefer {}.
- I personally like the backtick for its minimalist elegance. The {} stuff is horrible, especially when Jeff suggested stuff like {3,2}[some_command]. Looks Perlish. One new piece of syntax should be all that is considered.
- I agree that backtick is too visually subtle, too easily confused with apostrophe, and too easily invites people to imagine it's an opener that needs a corresponding closer to be the ideal expansion prefix. I'm not convinced an ideal prefix exists, though. TIP 103 did quite a thorough job of finding reasons to reject just about everything. {} as the prefix has several advantages already described by others, but I do not know how to defend it against charges of ugliness (and worse, Perlishness). It also turns fairly common syntax errors/typos into working code, making bugs harder to find.
- Actually, I like the leading backtick syntax best (alternately: dislike it the least).
- I believe I can live with either {} or backtic. I am oscillating with regard to which of the two I prefer.
- I started out thinking backtick would be best, but after seeing some arguments for {}, including maybe even {3 end-2}$foo, the {} syntax would be the one I favour. On the other hand: at the moment puts "This is {quite}$something" is perfectly legal, and it would remain so, if I understand correctly. However, it would look like an exception to the {}expand rule, at least for casual Tcl users. Confusion is not good.
- I like the backtick a lot more than {} or the @ symbol from the previous version of TIP 103. I find the @ ugly, but not nearly as ugly as {}. The suggestion that the {} syntax be extended to support operations like {2 3}$var seems to be further proof that it is the wrong choice. I agree that we should try not to break existing code, but if we are talking about Tcl 9 then there needs to be some freedom to make needed changes.
- I like the {} syntax that others have proposed. I'm sure that the beauty/ugliness of it is a matter of large debate, but it reminds me that I'm applying a *list* expansion to the associated arg. So it seems natural to me. I don't care if we allow parameters inside the {}'s or not. It just seems intuitive to me. The proposed {expand} is clearer, but more verbose. The {} seems shorter and better.
- Backtick and leading brace-pair are the current front-runners. Backtick has the disadvantages that can get lost in many fonts and that it doesn't permit fancy arguments (though I feel that second point is an advantage). Brace-pair has the disadvantage that it turns a fairly easily made syntax error into legal syntax.
4. How should the syntax work?
- a
- A ` must be followed by a single variable or command substitution, all else is a syntax error. Examples of valid constructs:
cmd `$apa `[foo miffo] `$arr([hej hopp])
- b
- Any word starting with is expanded if possible. Tcl(n) rules 4 and 5 do not apply after the since all "first char of word" rules are mutually exclusive. Additionally valid constructs:
cmd `word `[foo $apa]xx[oook $bepa] `$apa$bepa
- c
- Any word starting with is expanded if possible. All current word rules apply after the . Additionally valid constructs:
cmd `"[foo $apa] $bepa" `{some words}- a is ideal, b is barely acceptable, c feels really bad
- c is the most regular of the choices, and `{...} would actually be useful (if we had it a long time ago, we wouldn't have needed the list version of the switch command, for instance). This choice is also the easiest to explain.
- I would go for (c) with {}. Adding it in a 100% consistent way will reduce confusion.
- I think I prefer a out of these. c might be ok, hoping that nobody would actually abuse the syntax like that. I expect somebody would though.
- Definitely option (c), allowing for whatever the introductory syntax actually is. This is because it allows the programmer freedom to write their lists how they want and allows us to leverage the list parsing rules (which is Good.)
- Four answers: c
Argument Expansion Poll, part deux
The last poll shows support for the concept and a clear bias towards {}-syntax.
I will thus assume that a TIP suggesting global {}-syntax in Tcl 9.0 would be approved, and work from there.
1. Assuming that it has been decided that {}-syntax shall be added in 9.0, should we add it in 8.5 directly skipping any expand command?
- Three answers: Since it's backward compatible at the script level, I don't see a compelling reason to wait for 9.0. I don't think the incompatibilities in the Tcl_Parse* API's compel us to wait.
- I'm less sure about that, as I think that substantive changes to the endekalog should only be introduced at major versions (even if they don't have backward compatability problems.) However I also believe that we should do 9.0 as soon as possible anyway, so that's not actually a great problem; it is the right time to consider this, but we shouldn't be scared of bumping the major version.
- I can go along readily with that idea. Alas, knowing our team, I strongly suspect that we're going to have a lot of trouble settling on the content of a major release. If we do indeed have trouble achieving consensus, I'm nevertheless comfortable with inserting this feature in advance of a major release. (In short, I can go either way.)
- I'm not willing to go either way, because I think it is quite presumptuous to think we can knock out a 9.0 in any short order. 9.0 done right should take a lot of thought and input from a lot of people - IOW, I don't see it coming soon. This feature however is of value, upwards compatible, and not extremely difficult to implement. Note that this is orthogonal to how soon we start 9.0, because my point is that it won't be a short cycle (and 8.5 is already in development).
2. Should the more verbose {expand}-syntax be allowed too? I.e. {expand}$var {expand}[cmd]
- Three answers: No. It's just something to keep in mind in case we need finer control over argument expansion in the future.