TIP #144, its predecessor (TIP #103), and related proposals have
generated a tremendous amount of comment here on tcl-core, on the
Wiki, and on comp.lang.tcl.  Alas, the discussion has shed more heat
than light, and we remain no closer to a solution for the problem of
argument expansion than when we started.

The problem, as I see it, is that we are presented with too many
possibilities for solving the problem, each with its own
constituency. None of the possibilities has enough support to garner
two-thirds of the TCT's votes.  The reason that I have not called the
vote on TIP #144 is largely that I know it would be defeated given the
discourse as it currently stands. But none of the other proposals
stands a chance at present either.

    "He who is determined not to be satisfied with anything
    short of perfection will never do anything to please
    himself or others."        -- William Hazlitt, 1778-1830

I want to break this deadlock.  To this end, I want to take a poll
of the TCT, to determine the bounds of what will be acceptable.
I'm conducting this poll outside the TIP process because the TIP
process allows only for a "yes/no" vote.  Nevertheless, I wish
to regard the results as binding to the extent that:

  - I will regard it as impolite if any TCTer fails to respond
    to this poll but then votes against any argument-expansion
    proposal.

  - I will regard it as inappropriate behavior if any TCTer
    votes against an argument-expansion proposal in a manner
    inconsistent with his responses to this poll.

The large number of proposals makes it quite likely that I've missed
one or more of them.  I assure proposers that any omission is
accidental - please don't be unduly upset if your favorite is missing.

If your answer on any question differs depending on whether the
proposal is implemented in 8.5 versus 9.0, please indicate in
your response.

Please send votes to me by noon, Eastern Daylight Time, on Monday, 15
September 2003 [clock format 1063641600].

------------------------------------------------------------------------

QUESTIONS:

1. Is the argument-expansion problem worth solving at all? That is,
   would there be any proposal for argument expansion on which you
   would vote YES?  (Please read the "Rationale" and "Motivating
   Examples" of TIP #144 to understand how the problem is addressed
   in today's Tcl.)  Please vote YES or NO.

    For the following questions, please vote PREFER if the proposal is
    your preferred approach, OK if the proposal is not your preferred
    approach but you would not vote against it, or NO if the proposal
    is unacceptable.

    GENERALIZED PREFIX SYNTAX: A number of the proposals propose
    introducing new syntax to expand a variable, a command, or a word
    in general.

2. {}word (a generalization; {}$variable and {}[command] are
   special cases.)
    Advantages: Possible in 8.5; solves both command and variable
                expansion.
    Drawbacks: Thought by many to be ugly. Easily introduced as a
               typographical error by inadvertently omitting a space.
   Is this syntax acceptable? (PREFER/OK/NO)

3. {expand}word ({expand}$variable and {expand}[command])
    Advantages: Possible in 8.5; solves both command and variable
                expansion. Leaves other words in {} as additional
                possible syntax extensions, should such extensions
                ever be desired.
    Disadvantages: Verbose. Thought by many to be ugly. The fact
                   that it does leave additional syntax extensions
                   open may present an irresistable temptation to
                   monkey with the language.
   Is this syntax acceptable? (PREFER/OK/NO)

4. ""word (""$variable and ""[command])
    Advantages/drawbacks: Same as #2.
   Is this syntax acceptable? (PREFER/OK/NO)

5. `word (`$variable and `[command])
    Advantages: Thought by many to be prettier than #2/#3. Has
                parallels in Common Lisp and Scheme.
    Disadvantages: Not backward compatible, would have to wait
                   for 9.0.  Interacts badly with Tcl code that
                   composes shell scripts.  May tend to get lost
                   visually.
   Is this syntax acceptable? (PREFER/OK/NO)

6. @word (@$variable, @$command)
    Advantages: Thought by many to be prettier than #2/#3. Has
                parallels in Perl.
    Disadvantages: Not backward compatible. Interacts badly with
                   indexes in the text widget.
   Is this syntax acceptable? (PREFER/OK/NO)

     SPECIALIZED PREFIX SYNTAX: Several proposals deal only
     with variable expansion and not command expansion, or in some
     other way don't operate on a 'word' as defined in the
     Endecalogue.

7. $*variable and [*command].
    Advantages: Though elegant by some. $*word today doesn't
                actually do substitution, making it unlikely that
                the syntax is actually used.
    Disadvantages: Not backward compatible. Little is known about
                   whether command names beginning with the asterisk
                   appear "in the wild." Introduces two new syntactic
                   constructs instead of one. Result of usage within
                   a word (e.g. x[*command]y) is incompletely specified.
   A. Is $*variable acceptable? (PREFER/OK/NO)
   B. Is [*command] acceptable? (PREFER/OK/NO) 

8. $$variable and $[command]
    Advantages: Unlikely to be used in existing scripts, since the
                results are surprising.
    Disadvantages. Not formally backward compatible. Extremely
                   confusing to Perl users, who would expect
                   double-dereference.  Forecloses on any potential
                   future support of double-dereference. Again,
                   introduces two new syntactic constructs instead of
                   one. Result of usage within a word (e.g.,
                   x$[command]y) is incompletely specified.

   A. Is $$variable acceptable? (PREFER/OK/NO)
   B. Is $[command] acceptable? (PREFER/OK/NO)

    SURROUNDING SYNTAX: Some proposers prefer balanced syntax where
    the thing to be expanded is delimited at both ends.

9. `text`.
    Advantages: Parallel to the shells.  Perhaps less likely to be
                lost visually than a leading `.
    Disadvantages: Substitution within the backquotes is incompletely
                   specified. In particular, is it possible to expand
                   the result of a command whose arguments are
                   expanded with `text`? That is, is
                      command1 `[command2 `$args`]`
                   possible?
                   Not backward compatible.
   Is `text` syntax acceptable (PREFER/OK/NO)

    COMMAND SYNTAX: There are several proposals for defining argument
    expansion with a new command.

10. TIP #103 syntax.  Read the TIP for discussion of the syntax,
   advantages and disadvantages.
    Is TIP #103 syntax acceptable? (PREFER/OK/NO)

11. [expand {indexlist} command arg1 ... argN]
    This syntax accepts as its first argument a list of indices of
    arguments to be expanded.
    Advantages: No new syntax, can be done any time.
    Disadvantages: The separation of the index list from the arguments
                   to be expanded is a potential issue for
                   maintenance.

12. Additional flags to [eval], e.g., eval -expand 1 -- command $list
     Advantages: No new syntax in the Endecalogue.
     Disadvantages: Not backward compatible, adds complexity to
                    [eval] (and likely [uplevel], [interp eval],
                    [namespace eval], etc. as well).

    SPECIAL FUNCTIONAL FORM: One proposal is a "command" that
    actually is special syntax in functional form.

13. [lconvert]
    Joe Mistachkin has proposed a new command that would cause
    its argument to be expanded on return; one working name is
    [lconvert].  This proposal also exists in an [lexpand]
    variant as Tcl Patch #781929. (The patch does not function
    correctly with bytecoded commands.)
     Advantages: No new syntax, plus the [lconvert] (name may be
                 negotiated) is next to the argument to expand.
     Disadvantages: Many unresolved issues: what if [lconvert] is
                    aliased, renamed, [namespace import]ed,
                    overloaded in a namespace, ...? Truly
                    unfortunate interactions with the bytecode
                    compiler, which needs to make sure that the
                    command in
                      foreach x [command arg1 ... argN] { script }
                    is not an alias for [lconvert].  Uncertain
                    semantics when [lconvert] appears in string
                    catenation: command x[lconvert $y]z


------------------------------------------------------------------------
Kevin's votes:

1. YES
2. PREFER
3. OK
4. OK
5. OK (9.0), NO (8.5)
6. NO
7(A). OK (9.0), NO (8.5)
7(B). NO
8(A). NO
8(B). NO
9. NO  (I might be persuaded to change this vote with a more complete
        specification)
10. NO
11. OK
12. NO
13. NO. The unresolved issues make this proposal a non-starter.


--
73 de ke9tv/2, Kevin KENNY   GE Corporate Research & Development
kennykb@[...].com           P. O. Box 8, Bldg. K-1, Rm. 5B36A
                             Schenectady, New York 12301-0008 USA



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Tcl-Core mailing list
Tcl-Core@[...].net
https://lists.sourceforge.net/lists/listinfo/tcl-core