From Newsgroup: comp.lang.tcl

I've implemented a working prototype of TIP 672 - the $(expression) syntax for Tcl.

Instead of:
set result [expr {$a + $b * $c}]
puts "Total: [expr {$sum + $tax}]"

You can now write:
set result $($a + $b * $c)
puts "Total: $($sum + $tax)"

It compiles to identical bytecode as [expr {...}], so there's no performance penalty. Works great in strings, procs, and interactive mode.

Repository with code and examples in the readme (with details about the new code):

https://github.com/rocketship88/tcl-tip-672-prototype

The code is based on Tcl 9.1 source from last week, so the modified files should drop into current builds without conflicts to easily test this prototype.

The implementation is surprisingly simple - about 100 lines across two files in tclParse.c and tclNamesp.c. It creates a synthetic [expr {...}] string that the existing compiler optimizes normally.

One limitation: the synthetic strings leak memory (need core team input on the cleanup mechanism). Otherwise it's been working well in testing.

Thoughts? Does anyone see issues I haven't considered?

-et99

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

et99 <et99@rocketship1.me> wrote:

I've implemented a working prototype of TIP 672 - the $(expression) syntax for Tcl.

Instead of:
set result [expr {$a + $b * $c}]
puts "Total: [expr {$sum + $tax}]"

You can now write:
set result $($a + $b * $c)
puts "Total: $($sum + $tax)"

...

Thoughts? Does anyone see issues I haven't considered?

It conflicts with "empty string array names":

$ rlwrap tclsh
% set tcl_patchLevel
8.6.12
% array set "" [list a 1 b 2 c 4]
% array get ""
a 1 b 2 c 4
% puts $(c)
4
% puts $(a)
1
%

Now, naming an array "" is not commonly done, but I've used it (empty
string) sometimes for the destination array for ::cmdline::getopt and
friends for storing command line argument options.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Rich <rich@example.invalid> wrote:

et99 <et99@rocketship1.me> wrote:

I've implemented a working prototype of TIP 672 - the $(expression) syntax for Tcl.

Instead of:
set result [expr {$a + $b * $c}]
puts "Total: [expr {$sum + $tax}]"

You can now write:
set result $($a + $b * $c)
puts "Total: $($sum + $tax)"

...

Thoughts? Does anyone see issues I haven't considered?

It conflicts with "empty string array names":

$ rlwrap tclsh
% set tcl_patchLevel
8.6.12
% array set "" [list a 1 b 2 c 4]
% array get ""
a 1 b 2 c 4
% puts $(c)
4
% puts $(a)
1
%

Now, naming an array "" is not commonly done, but I've used it (empty string) sometimes for the destination array for ::cmdline::getopt and friends for storing command line argument options.

Just noticed that the "Tcl" manpage explicitly defines empty string as
a valid array name (emphasis added below):

Rule #8:

$name(index) Name gives the name of an array variable and index
gives the name of an element within that array. Name
must contain only letters, digits, underscores, and
namespace separators, and **may be an empty string**.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 10/17/2025 7:51 PM, Rich wrote:

Rich <rich@example.invalid> wrote:

et99 <et99@rocketship1.me> wrote:

I've implemented a working prototype of TIP 672 - the $(expression) syntax for Tcl.

Instead of:
set result [expr {$a + $b * $c}]
puts "Total: [expr {$sum + $tax}]"

You can now write:
set result $($a + $b * $c)
puts "Total: $($sum + $tax)"

...

Thoughts? Does anyone see issues I haven't considered?

It conflicts with "empty string array names":

$ rlwrap tclsh
% set tcl_patchLevel
8.6.12
% array set "" [list a 1 b 2 c 4]
% array get ""
a 1 b 2 c 4
% puts $(c)
4
% puts $(a)
1
%

Now, naming an array "" is not commonly done, but I've used it (empty
string) sometimes for the destination array for ::cmdline::getopt and
friends for storing command line argument options.

Just noticed that the "Tcl" manpage explicitly defines empty string as
a valid array name (emphasis added below):

Rule #8:

$name(index) Name gives the name of an array variable and index
gives the name of an element within that array. Name
must contain only letters, digits, underscores, and
namespace separators, and **may be an empty string**.

Yes, this is expressly documented in the readme at the repository as well as the TIP.

This is only targeted for version 9.1 and later. I see I did forget to explicitly mention that in my post. As with other 9.x new features, some incompatibilities will arise.

However, please note, this TIP does not preclude using an invisible name for an array, however, it does require that anyone who uses this (likely rare) construct would have to change over to one of two approaches to read the array (writing it still will work).

One by simply using {}'s

${(index)}

the other with a command

[set (index)]

statement.

This TIP was written to solve two issues with [expr]. if you look at the second reason mentioned in the TIP: that it improves security, I think you might find it a useful change for the 9.x system, given that only a minor change to coding would be required if one really still wants to use the array with no name.

Also, this TIP has no sponsor and has not been voted on. I am simply telling the tcl world that they can experiment (find bugs, express opinions on its implementation etc., tell me it's an awful idea) and otherwise play around with the change. Until now, one had to use JimTcl to test out this feature. Now it works in the very latest 9.1 Tcl.

-et99

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On Fri, 17 Oct 2025 23:04:51 -0700, et99 wrote:

On 10/17/2025 7:51 PM, Rich wrote:

Rich <rich@example.invalid> wrote:

et99 <et99@rocketship1.me> wrote:

I've implemented a working prototype of TIP 672 - the $(expression) syntax for Tcl.

Instead of:
set result [expr {$a + $b * $c}]
puts "Total: [expr {$sum + $tax}]"

You can now write:
set result $($a + $b * $c)
puts "Total: $($sum + $tax)"

...

Thoughts? Does anyone see issues I haven't considered?

[snip]

This TIP was written to solve two issues with [expr]. if you look at the second reason mentioned in the TIP: that it improves security, I think you might find it a useful change for the 9.x system, given that only a minor change to coding would be required if one really still wants to use the array with no name.

Also, this TIP has no sponsor and has not been voted on. I am simply telling the tcl world that they can experiment (find bugs, express opinions on its implementation etc., tell me it's an awful idea) and otherwise play around with the change. Until now, one had to use JimTcl to test out this feature. Now it works in the very latest 9.1 Tcl.

-et99

As an ordinary user I find this new syntax very appealing
and I hope it is adopted.

(Bikeshedding: regarding the parentheses, given that they
conflict with array syntax (in one rare case?) would an
alternative pair of delimiters work? For example:

set result $<$a + $b * $c>
puts "Total: $<$sum + $tax>"

Although presumably this would conflict with variable `$<`
which I suppose a Tcl refugee from Perl might use.)
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 10/18/2025 12:18 AM, Mark Summerfield wrote:

On Fri, 17 Oct 2025 23:04:51 -0700, et99 wrote:

On 10/17/2025 7:51 PM, Rich wrote:

Rich <rich@example.invalid> wrote:

et99 <et99@rocketship1.me> wrote:

I've implemented a working prototype of TIP 672 - the $(expression) syntax for Tcl.

Instead of:
set result [expr {$a + $b * $c}]
puts "Total: [expr {$sum + $tax}]"

You can now write:
set result $($a + $b * $c)
puts "Total: $($sum + $tax)"

...

[snip]

As an ordinary user I find this new syntax very appealing
and I hope it is adopted.

(Bikeshedding: regarding the parentheses, given that they
conflict with array syntax (in one rare case?) would an
alternative pair of delimiters work? For example:

set result $<$a + $b * $c>
puts "Total: $<$sum + $tax>"

Although presumably this would conflict with variable `$<`
which I suppose a Tcl refugee from Perl might use.)

Thanks for the positive feedback!

Regarding alternative delimiters - parentheses were chosen for several reasons:

1. Jim Tcl precedent - They've used $(...) successfully for years, proving it works in practice

2. Limited options - Tcl already uses [] for command substitution and {} for grouping/quoting. That leaves only <> and () as symmetrical ascii paired delimiters (using `' would seem odd).

3. Avoids escaping problems - Using <> would require escaping comparison operators:

$<$a \<= $b> # Need to escape <=, >=, <, >
$($a <= $b) # No escaping needed

4. Natural pairing - Parentheses nest and balance automatically, which is crucial for complex expressions

5. Common in expressions - Every language uses () for grouping: $(($a + $b) * $c) reads naturally

The empty array name conflict is real but extremely rare, and easily worked around with ${(index)} or [set (index)] when needed.

It's also worth noting that Tcl already has special-case code to handle empty array names - they're not a natural part of the array syntax. This suggests they were always an edge case rather than a core feature. Moving forward with $(...) in Tcl 9.x could actually simplify the parser by removing one special case while adding a more useful feature.

--et99

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On Sat, 18 Oct 2025 01:20:08 -0700, et99 wrote:

On 10/18/2025 12:18 AM, Mark Summerfield wrote:

On Fri, 17 Oct 2025 23:04:51 -0700, et99 wrote:

On 10/17/2025 7:51 PM, Rich wrote:

Rich <rich@example.invalid> wrote:

et99 <et99@rocketship1.me> wrote:

I've implemented a working prototype of TIP 672 - the $(expression) syntax for Tcl.

Instead of:
set result [expr {$a + $b * $c}]
puts "Total: [expr {$sum + $tax}]"

You can now write:
set result $($a + $b * $c)
puts "Total: $($sum + $tax)"

...

[snip]

As an ordinary user I find this new syntax very appealing
and I hope it is adopted.

(Bikeshedding: regarding the parentheses, given that they
conflict with array syntax (in one rare case?) would an
alternative pair of delimiters work? For example:

set result $<$a + $b * $c>
puts "Total: $<$sum + $tax>"

Although presumably this would conflict with variable `$<`
which I suppose a Tcl refugee from Perl might use.)

Thanks for the positive feedback!

Regarding alternative delimiters - parentheses were chosen for several reasons:

1. Jim Tcl precedent - They've used $(...) successfully for years, proving it works in practice

2. Limited options - Tcl already uses [] for command substitution and {} for grouping/quoting. That leaves only <> and () as symmetrical ascii paired delimiters (using `' would seem odd).

3. Avoids escaping problems - Using <> would require escaping comparison operators:

$<$a \<= $b> # Need to escape <=, >=, <, >
$($a <= $b) # No escaping needed

4. Natural pairing - Parentheses nest and balance automatically, which is crucial for complex expressions

5. Common in expressions - Every language uses () for grouping: $(($a + $b) * $c) reads naturally

The empty array name conflict is real but extremely rare, and easily worked around with ${(index)} or [set (index)] when needed.

It's also worth noting that Tcl already has special-case code to handle empty array names - they're not a natural part of the array syntax. This suggests they were always an edge case rather than a core feature. Moving forward with $(...) in Tcl 9.x could actually simplify the parser by removing one special case while adding a more useful feature.

--et99

Thanks for the explanation. I really hope the `$(...)` syntax is adopted.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

et99 <et99@rocketship1.me> posted:

I've implemented a working prototype of TIP 672 - the $(expression)
syntax for Tcl.

Implementing this would make my TIP 676 redundant, but I wouldn't shed
any tears for that: https://core.tcl-lang.org/tips/doc/trunk/tip/676.md
This notation is more compact and has a simpler implementation than mine.

I do like the idea of having {*}{expression} as one instance of a
generalised expansion system as proposed in https://wiki.tcl-lang.org/page/Expanding+the+Expansion+Prefix
but perhaps that's too radical.

I certainly agree that a streamlined expression syntax would eliminate
one of the biggest warts that tends to put people off Tcl.
--
Colin Macleod ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ https://cmacleod.me.uk

FEED FEED FEED FEED FEED FEED FEED FEED
GAZA GAZA GAZA GAZA GAZA GAZA GAZA GAZA
NOW! NOW! NOW! NOW! NOW! NOW! NOW! NOW!
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Colin Macleod <user7@newsgrouper.org.invalid> posted:

I do like the idea of having {*}{expression} as one instance of a
generalised expansion system as proposed in https://wiki.tcl-lang.org/page/Expanding+the+Expansion+Prefix
but perhaps that's too radical.

Correction, I meant to write {=}{expression} Doh!
--
Colin Macleod ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ https://cmacleod.me.uk

FEED FEED FEED FEED FEED FEED FEED FEED
GAZA GAZA GAZA GAZA GAZA GAZA GAZA GAZA
NOW! NOW! NOW! NOW! NOW! NOW! NOW! NOW!
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 18/10/25 09:23, et99 wrote:

I've implemented a working prototype of TIP 672 - the $(expression)
syntax for Tcl.

Instead of:
-a set result [expr {$a + $b * $c}]
-a puts "Total: [expr {$sum + $tax}]"

You can now write:
-a set result $($a + $b * $c)
-a puts "Total: $($sum + $tax)"

It compiles to identical bytecode as [expr {...}], so there's no
performance penalty. Works great in strings, procs, and interactive mode.

Repository with code and examples in the readme (with details about the
new code):

https://github.com/rocketship88/tcl-tip-672-prototype

The code is based on Tcl 9.1 source from last week, so the modified
files should drop into current builds without conflicts to easily test
this prototype.

The implementation is surprisingly simple - about 100 lines across two
files in tclParse.c and tclNamesp.c. It creates a synthetic [expr {...}] string that the existing compiler optimizes normally.

One limitation: the synthetic strings leak memory (need core team input
on the cleanup mechanism). Otherwise it's been working well in testing.

Thoughts? Does anyone see issues I haven't considered?

-et99

Oh yes, I love that. I've been sticking to 8.6 on our work servers,
because if it ain't broke ... but I'd definitely upgrade to 9 for that
alone.

Do general users get a chance to vote, if this is at a voteable stage?

Jonathan.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 10/18/2025 2:47 PM, Jonathan Kelly wrote:

On 18/10/25 09:23, et99 wrote:

I've implemented a working prototype of TIP 672 - the $(expression) syntax for Tcl.

Instead of:
-a-a set result [expr {$a + $b * $c}]
-a-a puts "Total: [expr {$sum + $tax}]"

You can now write:
-a-a set result $($a + $b * $c)
-a-a puts "Total: $($sum + $tax)"

It compiles to identical bytecode as [expr {...}], so there's no performance penalty. Works great in strings, procs, and interactive mode.

Repository with code and examples in the readme (with details about the new code):

https://github.com/rocketship88/tcl-tip-672-prototype

The code is based on Tcl 9.1 source from last week, so the modified files should drop into current builds without conflicts to easily test this prototype.

The implementation is surprisingly simple - about 100 lines across two files in tclParse.c and tclNamesp.c. It creates a synthetic [expr {...}] string that the existing compiler optimizes normally.

One limitation: the synthetic strings leak memory (need core team input on the cleanup mechanism). Otherwise it's been working well in testing.

Thoughts? Does anyone see issues I haven't considered?

-et99

Oh yes, I love that. I've been sticking to 8.6 on our work servers, because if it ain't broke ... but I'd definitely upgrade to 9 for that alone.

Do general users get a chance to vote, if this is at a voteable stage?

Jonathan.

Thanks for the enthusiastic support!

Currently, TIP 672 doesn't have a sponsor yet, which is required before it can move to a vote. However, there's positive interest from the core team, and it may be discussed in their next biweekly telco on Monday.

General users (you and me) don't vote on TIPs directly - the Tcl Core Team makes those decisions. However, community feedback like yours is valuable and does influence the discussion. Expressing support on comp.lang.tcl and the mailing lists helps show there's genuine user demand for the feature.

The working prototype is available now if you want to experiment with it:

https://github.com/rocketship88/tcl-tip-672-prototype

Since the code is a derivative of the latest 9.1 code (9.1a1) within the last 5 days, if you know how to build from sources, all you'd need to do is replace the two files (tclParse.c and tclNamesp.c) in the generic folder, with those 2 in the repository. No need to worry about using diff's etc. Then just build into a temporary folder.

(I'm on windows, so I have batch scripts to do that including builds with symbols so I can debug with visual studio 2022, which is a truly superb tool.)

Your feedback on real-world usage would be helpful as the discussion moves forward!

--et99

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 10/17/2025 10:48 PM, Rich wrote:

Thoughts? Does anyone see issues I haven't considered?

It conflicts with "empty string array names":

...

Now, naming an array "" is not commonly done, but I've used it (empty
string) sometimes for the destination array for ::cmdline::getopt and
friends for storing command line argument options.

That is one of the two things that came to my mind.

The other one is the evaluation order of individual words that make up a command. Currently, everything between curly braces "{}" are delayed
for variable substitutions, command evaluations, etc.

However, it looks like stuff between "$(" and the matching ")" are
treated same as "{}", which would alter the basic rules of the language.

Perhaps adopting a new syntax like "{**}{...}" or even "{=}{...}" like
someone else suggested, might be easier to pull into the current rules.

Personally, I am kind of surprised that "expr {}" seems to be disliked.
I also don't see how "$()" improves things but that's just me.

Interesting project.


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

saito <saitology9@gmail.com> wrote:

On 10/17/2025 10:48 PM, Rich wrote:

Thoughts? Does anyone see issues I haven't considered?

It conflicts with "empty string array names":

...

Now, naming an array "" is not commonly done, but I've used it (empty
string) sometimes for the destination array for ::cmdline::getopt and
friends for storing command line argument options.

That is one of the two things that came to my mind.

...

Personally, I am kind of surprised that "expr {}" seems to be disliked.
I also don't see how "$()" improves things but that's just me.

It is identical to Bash's process substitution operator [1], beyond that,
it is less characters than [expr {}].

But I very much suspect that it will do little to quiet the complaints
from "other language users" who complain about [expr]. It will change
their complaints, but it won't quiet them. Because what they are
really complaining about is they want to see something like this:

some-func $a+$c ($ab+$cd/($ef-$gh))

Or more likely, what they 'really' are complaining about is that Tcl
does not look like this to them:

some-func a+c (ab+cd/(ef-gh))



[1] and if it were to copy Bash, it would be $(( )) for math
operations instead of $( )
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 10/19/2025 4:11 PM, Rich wrote:

Personally, I am kind of surprised that "expr {}" seems to be disliked.
I also don't see how "$()" improves things but that's just me.

It is identical to Bash's process substitution operator [1], beyond that,
it is less characters than [expr {}].

I see. I have only used bash to set up aliases for commands that I use frequently so this is new to me.

But I very much suspect that it will do little to quiet the complaints
from "other language users" who complain about [expr]. It will change
their complaints, but it won't quiet them. Because what they are
really complaining about is they want to see something like this:

some-func $a+$c ($ab+$cd/($ef-$gh))

Or more likely, what they 'really' are complaining about is that Tcl
does not look like this to them:

some-func a+c (ab+cd/(ef-gh))

It makes sense now and I agree. I see it as, everything comes with their
own quirks, like roses and their thorns, so perhaps this is something
about Tcl that we just need to accept with no apologies.

However, it just occurred to me that perhaps there is a better defense,
and I am not certain there needs to be one:

The desired syntax (from your examples above) is limited in
functionality: it performs the calculations once, right there. To have
it repeated on events, triggers, etc., one will need to write a function around these expressions.

However, Tcl offers more flexibility: you can have your expressions
inlined as above, or you can have them execute later, without any extra
set up or wrapper functions.

Just my 2 cents I guess.


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 10/19/2025 12:28 PM, saito wrote:

On 10/17/2025 10:48 PM, Rich wrote:

Thoughts? Does anyone see issues I haven't considered?

It conflicts with "empty string array names":

...

Now, naming an array "" is not commonly done, but I've used it (empty
string) sometimes for the destination array for ::cmdline::getopt and
friends for storing command line argument options.

That is one of the two things that came to my mind.

The other one is the evaluation order of individual words that make up a command.-a Currently, everything between curly braces "{}" are delayed for variable substitutions, command evaluations, etc.

However, it looks like stuff between "$(" and the matching ")" are treated same as "{}", which would alter the basic rules of the language.

Perhaps adopting a new syntax like "{**}{...}" or even "{=}{...}" like someone else suggested, might be easier to pull into the current rules.

Personally, I am kind of surprised that "expr {}" seems to be disliked. I also don't see how "$()" improves things but that's just me.

Interesting project.

Thanks for the feedback.

First, the easiest way to understand $(...) is that it is implemented as though it was a C #define macro but without a pre-processor step.

The $(...) is transformed immediately into [expr {...}] before the rest of the parser ever sees it. This means that all $(...) use is the same as braced [expr] use.

But [expr] is untouched and will work exactly the same as it always has.

So, where's the benefit?

Suppose you have this, where someone forgot to brace the expression:

set bad {[file delete somefile.dat]} ;# or perhaps it came in from the wild
set result [expr $bad + 2]

This will throw the following error:

can't use empty string as operand of "+"

But your file is deleted anyway, since $bad was substituted before [expr] ever got it, and it looks exactly like this:

set result [expr [file delete somefile.dat] + 2]

which is valid [expr] with command substitution. To protect against this, tcl recommends all expressions be inside of braces, like so,

set result [expr {$bad}]

which would cause [expr] to evaluate the expression and reject it, because $bad in this context must be a number, not an expression or command.

In addition to the security, the expression will be compiled to byte-code which is more efficient.

So [expr] has 2 mechanisms depending on bracing while $(...) has only 1. It is an additional way to do expressions safely not a replacement for [expr].

I won't reveal more here, but there is a new security injection bug in version 9.x that $(...) would solve, if approved.


------



As to the one minor incompatibility: the array with no name, I suggest that all uses of that tcl feature should at minimum use braces, like so:

set array_value_at_index ${(index)}

This would eliminate the conflict $(...) creates, and would highlight the fact that the user is really using a variable name that is not comprised of the standard letters, numbers, colons, and underscores, and didn't accidentally forget to include a name.

Yes, the manual states that the name can be empty, but the parser has to include special code to handle this, suggesting that it was an afterthought and not there in the beginning.

I'm the first to admit that my choice of variable names is not always what it should be, but to go so far as to have a name with no name, well, I'm at a loss to see the value there. But to each ...

Note that with $(...) there is no conflict with creating an array variable with the empty name, since that would be written as,

set (index) some-value

It's only when using $ substitution that there's a conflict. And there's also [set] for variables with really exotic names that can also work with empty names (and with the non-array variable "" also).

set value [set (index)]

So the ability is not going away, it just requires some proactive changes. If users would use one of the two methods above today, whether this $(...) feature is implemented or not, their usage would be future proofed.

Thanks

--et99


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 10/19/2025 1:30 PM, saito wrote:

On 10/19/2025 4:11 PM, Rich wrote:

[snip]

But I very much suspect that it will do little to quiet the complaints
from "other language users" who complain about [expr].-a It will change
their complaints, but it won't quiet them.-a Because what they are
really complaining about is they want to see something like this:

some-func $a+$c ($ab+$cd/($ef-$gh))

Or more likely, what they 'really' are complaining about is that Tcl
does not look like this to them:

some-func a+c (ab+cd/(ef-gh))

It makes sense now and I agree. I see it as, everything comes with their own quirks, like roses and their thorns, so perhaps this is something about Tcl that we just need to accept with no apologies.

However, it just occurred to me that perhaps there is a better defense, and I am not certain there needs to be one:

The desired syntax (from your examples above) is limited in functionality: it performs the calculations once, right there. To have it repeated on events, triggers, etc., one will need to write a function around these expressions.

However, Tcl offers more flexibility: you can have your expressions inlined as above, or you can have them execute later, without any extra set up or wrapper functions.

Just my 2 cents I guess.

Good point Rich! You're right that $(expr) won't satisfy people who want Python/C-style syntax - that's not the goal.

The goal is to make the recommended, safe way (braced expressions) easier to read and write for people who already understand and appreciate Tcl's model. It's about improving Tcl for Tcl users, not converting people from other languages.

Although, your first example isn't far from this TIP's proposal,

some-func $a+$c ($ab+$cd/($ef-$gh))

becomes

some-func $($a+$c) $($ab+$cd/($ef-$gh))

While this only added 4 characters, it also ensures that the result is compiled byte-code and free of injection attacks.


Regarding saito's point on immediate vs. delayed values: $(...) works exactly the same as $var in this regard - nothing new to learn.

If you need values looked up at event time:

button ... -command {puts $::var}
button ... -command {puts $($::var - 2)}


If you need current values repeatedly:

button ... -command [list puts $::var]
button ... -command [list puts $($::var - 2)]


the same patterns Tcl users already know - $(...) fits right in.

--et99

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 10/19/2025 11:46 PM, et99 wrote:

Regarding saito's point on immediate vs. delayed values: $(...) works exactly the same as $var in this regard - nothing new to learn.

Thank you. I got that impression from your post from the start. What I
was hinting at was that, the 12 rules of the language would have to be modified because of the word/argument expansion semantics which is
suppressed only for curly braces. Unless I am mistaken, the "$(...)"
would need to be added as an exception or a new rule or something like that.


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 10/20/2025 11:45 AM, saito wrote:

On 10/19/2025 11:46 PM, et99 wrote:

Regarding saito's point on immediate vs. delayed values: $(...) works exactly the same as $var in this regard - nothing new to learn.

Thank you. I got that impression from your post from the start.-a What I was hinting at was that, the 12 rules of the language would have to be modified because of the word/argument expansion semantics which is suppressed only for curly braces.-a Unless I am mistaken, the "$(...)" would need to be added as an exception or a new rule or something like that.

Yes, you are correct.

Rule 8, currently called "Variable substitution" would need to be changed. Perhaps it would then be called $ substitution. I think that $(expression) would fit in nicely after ${name}.

The sentence in $name(index) that says "and may be an empty string" would then be moved down to the ${name} section since that would be the appropriate way to use a null string as an array name *or* a variable name.

BTW, the manual is incomplete here, since name can also be null for a non-array variable but this is never mentioned:

% set {} foo
foo
% puts ${}
foo
% unset {}
% set "" nothing
nothing
% puts ${}
nothing
% info glob
{} tcl_rcFileName...
% string length [lindex [info glob] 0]
0
% set foo $
$

So, it's not a variable with the name "{}" it is the null string that is the name. And the ${} is required if you want the null variable, since otherwise a $ alone is not a substitution.

--et99

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 10/20/2025 2:48 PM, et99 wrote:

On 10/20/2025 11:45 AM, saito wrote:

Thank you. I got that impression from your post from the start.-a What I was hinting at was that, the 12 rules of the language would have to be modified because of the word/argument expansion semantics which is suppressed only for curly braces.-a Unless I am mistaken, the "$(...)" would need to be added as an exception or a new rule or something like that.

And yes again, you are correct, it would need to mention that $(...) suppresses direct substitution of variables or commands which are passed on to expr (or probably the compiler) that does further validation and evaluation.

Hmmm, I just now discovered something I hadn't realized:

% set (1) one
one
% set ind 1
1
% set ($ind)
one
% puts ${($ind)}
can't read "($ind)": no such element in array

This means that the ${name} workaround for an empty array name will NOT work for an index that is a $var. So, this means that the [set ($var)] method would have to be used, not the ${($var)}. So, this is part of the rule for ${name} which also does not substitute inside {}'s but is not the same as the rule on words enclosed in {}.

Learn something new about tcl all the time...

-et99

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl


Hello

I currently do not see the benefit of this proposal, except some char less to type.
IMHO expr has some problems or room for enhancements:
1. Double evaluation of arguments
Could be solved with a new command with only 1 argument
2. Returns only one value
See p.e. tip 647 syntax
3. Access to tcl-variables with $-syntax
This would require a new expression parser
4. Anything else?

Do the tip 672 solve one of these points?


Regards
rene
PS. This is a copy from my post to tcl-core
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

et99 <et99@rocketship1.me> posted:

On 10/18/2025 4:30 AM, Colin Macleod wrote:

I certainly agree that a streamlined expression syntax would eliminate
one of the biggest warts that tends to put people off Tcl.

Thank you for the support and for your willingness to consolidate efforts! It's encouraging to see convergence around addressing this long-standing issue.

After seeing lots of quibbling about compatibility on the tcl-core list
I'm thinking maybe it's not yet time to write off my own suggestion.
So I sent the following to tcl-core:

========================================================================
Hi All, perhaps it's time to boost my own expr proposal again.

I like the [= <expr>] idea, but simply aliasing "=" to expr doesn't help
much because you still need to brace the expression to avoid double- substitution problems. Unbraced works ok for the simple examples Florent gives, but in general is problematic, e.g.

set x {[exec cat /secret/file >/dev/tty]} ;# x might be set from user input ...
string range "abcdef" 1 end-[= $x-2] ;# user sees secret file :-(

My own TIP 676 is a proposal to make [= <expression>] usable and safe.
It has the advantage of not requiring any change to the dodekalogue and
is fully compatible with existing code. It also can be used anywhere
that [] gets expanded including within quoted strings, which is not the
case for the {=}{expr} proposal.

There are some downsides:
- Operators and operands need to be separated with spaces, i.e. [= $x - 2]
not [= $x-2]
- Only numerical and boolean values can be supported, not string values
- Lazy evaluation of && || ?: is not supported
- The implementation is a little more complicated since it can't use the
existing [expr] parser. I supplied a Tcl prototype, linked from the TIP,
actual implementation would require translating this into C.

I worked on this in 2023 but-aput it aside because everyone was focussed
on getting 9.0 released, then I moved on to a different project. I think
it's worth considering now that [expr] simplification is back in the spotlight.

Colin.
========================================================================

My TIP is at https://core.tcl-lang.org/tips/doc/trunk/tip/676.md .
I do think any of the proposals on the table would be better than
doing nothing though.
--
Colin Macleod ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ https://cmacleod.me.uk

FEED FEED FEED FEED FEED FEED FEED FEED
GAZA GAZA GAZA GAZA GAZA GAZA GAZA GAZA
NOW! NOW! NOW! NOW! NOW! NOW! NOW! NOW!
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 10/22/2025 3:12 AM, Colin Macleod wrote:

et99 <et99@rocketship1.me> posted:

On 10/18/2025 4:30 AM, Colin Macleod wrote:

I certainly agree that a streamlined expression syntax would eliminate
one of the biggest warts that tends to put people off Tcl.

Thank you for the support and for your willingness to consolidate efforts! >> It's encouraging to see convergence around addressing this long-standing issue.

After seeing lots of quibbling about compatibility on the tcl-core list
I'm thinking maybe it's not yet time to write off my own suggestion.
So I sent the following to tcl-core:

========================================================================
Hi All, perhaps it's time to boost my own expr proposal again.

I like the [= <expr>] idea, but simply aliasing "=" to expr doesn't help
much because you still need to brace the expression to avoid double- substitution problems. Unbraced works ok for the simple examples Florent gives, but in general is problematic, e.g.

set x {[exec cat /secret/file >/dev/tty]} ;# x might be set from user input
...
string range "abcdef" 1 end-[= $x-2] ;# user sees secret file :-(

My own TIP 676 is a proposal to make [= <expression>] usable and safe.
It has the advantage of not requiring any change to the dodekalogue and
is fully compatible with existing code. It also can be used anywhere
that [] gets expanded including within quoted strings, which is not the
case for the {=}{expr} proposal.

There are some downsides:
- Operators and operands need to be separated with spaces, i.e. [= $x - 2]
not [= $x-2]
- Only numerical and boolean values can be supported, not string values
- Lazy evaluation of && || ?: is not supported
- The implementation is a little more complicated since it can't use the
existing [expr] parser. I supplied a Tcl prototype, linked from the TIP,
actual implementation would require translating this into C.

I worked on this in 2023 but-aput it aside because everyone was focussed
on getting 9.0 released, then I moved on to a different project. I think it's worth considering now that [expr] simplification is back in the spotlight.

Colin. ========================================================================

My TIP is at https://core.tcl-lang.org/tips/doc/trunk/tip/676.md .
I do think any of the proposals on the table would be better than
doing nothing though.

Colin:

Yes, the community approach sometimes leads to the inability to make a decision one way or the other. I've put the wraps on this, you can see my recent posting on the core list.

I've modified my code to have a #define mode option which can implement either of the original syntax $(...) or Don's idea of $=(...) where the = could be any of the non-substitution characters, like @ or ^ which I believe eliminates the conflict with the null string array variable name. Just 1 extra character.

I was encouraged to find that several core team members were quite supportive, but I needed to finalize my prototype and let them make the next move.

Feel free to use the code for your own implementation, by using the macro approach, it's under 100 lines, and you might be able to build a safe [= ...] that feeds into expr braced expressions.

I chose the $ injection point you could look at the [...] interface, or write up a C extension that could do the same thing. It's not that difficult to build a command token and pass it off to if you wedge it in at the right place.

Good luck with your proposal.

-et99

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

et99 <et99@rocketship1.me> wrote:

I've modified my code to have a #define mode option which can
implement either of the original syntax $(...) or Don's idea of
$=(...) where the = could be any of the non-substitution characters,
like @ or ^ which I believe eliminates the conflict with the null
string array variable name. Just 1 extra character.

Equals seems fine as a character, and at least suggests "math" as well
as making a math equation somewhat read like a written one:

set a $=($y*4+$z**2) ;# set a "equals" to 4*$y plus $z squared

It also, it seems, does not conflict with any existing code usage of $
as $= does not expand:

$ rlwrap tclsh
% array set = [list a 1 b 2 c 3]
% puts $=(b)
$=(b)
% puts $=(b)
$=(b)
% set =(b)
2
% puts ${=(b)}
2

So while one can have an array named =, one could not use plain $=() to
access it, so using $= for your new math operator won't conflict with
any existing code (which would have already had to use 'set' or ${} to
access an "array named equals").

I was encouraged to find that several core team members were quite supportive, but I needed to finalize my prototype and let them make
the next move.

I suggest falling behind the $=() syntax, as it looks to remove *any* complaints of breaking legacy code.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 10/22/2025 5:56 AM, Rich wrote:

Equals seems fine as a character, and at least suggests "math" as well
as making a math equation somewhat read like a written one:

set a $=($y*4+$z**2) ;# set a "equals" to 4*$y plus $z squared

It also, it seems, does not conflict with any existing code usage of $
as $= does not expand:

$ rlwrap tclsh
% array set = [list a 1 b 2 c 3]
% puts $=(b)
$=(b)
% puts $=(b)
$=(b)
% set =(b)
2
% puts ${=(b)}
2

So while one can have an array named =, one could not use plain $=() to access it, so using $= for your new math operator won't conflict with
any existing code (which would have already had to use 'set' or ${} to
access an "array named equals").

[snip]

I suggest falling behind the $=() syntax, as it looks to remove *any* complaints of breaking legacy code.

Thanks Rich for verifying that.

I like your example emphasizing the set ... = ... math expression, as indeed that does seem to fit well. If you find this proposal to your liking, I would encourage you to send a note off to the core email list.

Input from the outer Tcl community can be valuable to help the core make a decision.

--et99

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 22/10/2025 20:48, et99 wrote:

<big, big snip>

If you find this proposal to your
liking, I would encourage you to send a note off to the core email list.

Input from the outer Tcl community can be valuable to help the core make
a decision.

I've tried to follow this discussion since it started a week ago. I've
finally got around to taking a peek at the two TIPs centrally involved -
672 and 676.

Throughout, I've found it hard to understand what problem the two
improvement proposals were attempting to fix, and I must admit that
reading the documents hasn't really helped me.

However, from my limited reading of the TIPs and more fully committed
reading of the thread it seems that there is a concern that:

o The existing [expr] syntax is hard to read for those who are not
familiar with Tcl; and
o Even those who are fairly familiar find it difficult to use [expr]
to get something that not only works, but works properly, i.e. without
opening unfortunate security holes.

I'm very much minded to leave things as they are. My feeling is that if
you find it difficult to obey the syntax rules of a language then either
you should try harder, or you should find a different language. As for
opening security holes I believe that any security system risks being cicumvented and at bottom you have to trust language users to be able to security-proof their own code.

In summary I propose, much like the author of TIP 676 elsewhere in this discussion, that doing nothing is a superior option to following up
either of the proposals.

What's the core email address, and what subject should I use in a
message to make my opinion known?


Alan
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Alan Grunwald <nospam.nurdglaw@gmail.com> posted:

What's the core email address, and what subject should I use in a
message to make my opinion known?

The list email address is Tcl-Core@lists.sourceforge.net

I just made yet another proposal: https://sourceforge.net/p/tcl/mailman/message/59251190/
--
Colin Macleod ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ https://cmacleod.me.uk

FEED FEED FEED FEED FEED FEED FEED FEED
GAZA GAZA GAZA GAZA GAZA GAZA GAZA GAZA
NOW! NOW! NOW! NOW! NOW! NOW! NOW! NOW!
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Colin Macleod <user7@newsgrouper.org.invalid> posted:

I just made yet another proposal: https://sourceforge.net/p/tcl/mailman/message/59251190/

I have now modified TIP 676 to this later proposal:
https://core.tcl-lang.org/tips/doc/trunk/tip/676.md
and made an implementation which is on branch cgm-equals-command
in the Tcl core repository:
https://core.tcl-lang.org/tcl/timeline?r=cgm-equals-command

The main difference from my earlier proposal is to treat bare words
without $ as variable names in the expression. Some TCT members are
supportive, others less so. I am hoping it can be voted on early in
the new year, in time to be included in Tcl9.1a1.
--
Colin Macleod ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ https://cmacleod.me.uk

FEED FEED FEED FEED FEED FEED FEED FEED
GAZA GAZA GAZA GAZA GAZA GAZA GAZA GAZA
NOW! NOW! NOW! NOW! NOW! NOW! NOW! NOW!
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 17/10/2025 23:23, et99 wrote:

I've implemented a working prototype of TIP 672 - the $(expression)
syntax for Tcl.

Instead of:
-a set result [expr {$a + $b * $c}]
-a puts "Total: [expr {$sum + $tax}]"

You can now write:
-a set result $($a + $b * $c)
-a puts "Total: $($sum + $tax)"

...

Thoughts? Does anyone see issues I haven't considered?

One biggy: It's another irregularity making programming, which is
difficult, even more so. It doesn't take long for them to compose
together into development gridlock.

Tcl has so far been a bastion of syntactically NotRubbish. Please try to
keep it so for all our sakes.

If it's just a matter of typing '[expr ' instead of '$(' then don't do
it without super special reasons, and if the expression syntax has lots
of pitfalls it would be a grave error to give it the prime syntactic
position.

Because of the workload to do useful things correctly, the Tcl
maintainers are already simplifying Tcl with otherwise needless breaking changes. If you make it harder for them and also harder for users to
understand Tcl and predict what and how to do things from documentation
then it'll just devalue Tcl.
--
Tristan Wibberley

The message body is Copyright (C) 2025 Tristan Wibberley except
citations and quotations noted. All Rights Reserved except that you may,
of course, cite it academically giving credit to me, distribute it
verbatim as part of a usenet system or its archives, and use it to
promote my greatness and general superiority without misrepresentation
of my opinions other than my opinion of my greatness and general
superiority which you _may_ misrepresent. You definitely MAY NOT train
any production AI system with it but you may train experimental AI that
will only be used for evaluation of the AI methods it implements.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> posted:

On 17/10/2025 23:23, et99 wrote:

I've implemented a working prototype of TIP 672 - the $(expression)
syntax for Tcl.

...

One biggy: It's another irregularity making programming, which is
difficult, even more so. It doesn't take long for them to compose
together into development gridlock.

Hi Tristan, AIUI Eric (et99) has pretty much given up on his TIP 672
proposal now. Recently he has been quite supportive towards my alternative which is TIP 676 - https://core.tcl-lang.org/tips/doc/trunk/tip/676.md .

TIP 676 just proposes a command called `=` which would allow the examples
Eric gave to be written as:
set result [= a + b * c]
puts "Total: [= sum+tax]"

This would not replace `expr`, it's just an alternative compact form for numerical/logical calculations, with no impact on the basic Tcl parsing
rules or the rest of the language.

So I'm wondering if you would consider this "NotRubbish" or not?
--
Colin Macleod ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ https://cmacleod.me.uk

FEED FEED FEED FEED FEED FEED FEED FEED
GAZA GAZA GAZA GAZA GAZA GAZA GAZA GAZA
NOW! NOW! NOW! NOW! NOW! NOW! NOW! NOW!
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 12/12/2025 17:10, Colin Macleod wrote:

Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> posted:

On 17/10/2025 23:23, et99 wrote:

I've implemented a working prototype of TIP 672 - the $(expression)
syntax for Tcl.

...

One biggy: It's another irregularity making programming, which is
difficult, even more so. It doesn't take long for them to compose
together into development gridlock.

Hi Tristan, AIUI Eric (et99) has pretty much given up on his TIP 672
proposal now. Recently he has been quite supportive towards my alternative which is TIP 676 - https://core.tcl-lang.org/tips/doc/trunk/tip/676.md .

TIP 676 just proposes a command called `=` which would allow the examples Eric gave to be written as:
set result [= a + b * c]
puts "Total: [= sum+tax]"

This would not replace `expr`, it's just an alternative compact form for numerical/logical calculations, with no impact on the basic Tcl parsing
rules or the rest of the language.

So I'm wondering if you would consider this "NotRubbish" or not?

At the risk of later needing to introduce new adjectives later due to my
polite use of Rubbish at this time where I would have preferred a
stronger adjective, that one seems to more NotRubbish to me.

Whether '=' is the best name for the procedure and whether it's a good
DSL to include and thus naturalise is another matter. I haven't read the details of the DSL or considered how it references names in its related
frames and how people will suffer the availability of both $x and x in
the DSL. But as a short-form it's not so bad as $().

{=}{ ... } also seems NotRubbish to me on the same "regularity" factor I
was considering for rejecting the previously posted idea, but regularity
needs can go deeper. It allows for DSLs unaffected by the outer language
except for {} matching which isn't so bad and might be good if the DSL
doesn't re-use $references syntax or does so only with total consistency
with the outer language whereever they reference variables in tcl frames
(and then if their implementation uses sufficient common implementation
with the tcl interpreter}, and allows for generalised parameterisation
of the DSL in future without problematic irregularity.

I think I've exhausted my useful input because of my limited practical
Tcl intuition.
--
Tristan Wibberley

The message body is Copyright (C) 2025 Tristan Wibberley except
citations and quotations noted. All Rights Reserved except that you may,
of course, cite it academically giving credit to me, distribute it
verbatim as part of a usenet system or its archives, and use it to
promote my greatness and general superiority without misrepresentation
of my opinions other than my opinion of my greatness and general
superiority which you _may_ misrepresent. You definitely MAY NOT train
any production AI system with it but you may train experimental AI that
will only be used for evaluation of the AI methods it implements.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

I've looked again at the two competing proposals for an alternative to
the `[eval {rCa}]` syntax:

Current: set c [eval {sqrt($a**2 + $b**2)}]
Tip 672: set c $(sqrt($a**2 + $b**2))
Tip 676: set c [= sqrt(a**2 + b**2)]

When I first saw Tip 672 I was quite enthusiastic because of its
compactness. The downsiderCowhich I now think ought to be a show-stopperrCois that it changes the fundamental syntax of the language and changes the 12 rules.

As for Tip 676, it doesn't appear to me to change the 12 rules, instead it introduces a new global function `=`. However, it also introduces a novel
DSL rather than using `eval`'s DSL. This seems to require a lot of
additional learning, particularly the dropping of the `$` for variable accesses, the fact that the string operators, `in`, `ni`, `eq`, `ne`, `lt`, `gt`, `le`, `ge` are not supported, the fact that `true` and `false` aren't supported, as well as the possible confusion over array accesses.

I don't think either proposal will make Tcl easier to learn or use.

Tip 672 would introduce a new additional fundamental syntax to learn that is confusingly similar to array access.

Tip 676 would introduce an incomplete alternative to `eval` which would mean that sometimes programmers would need to use `eval` anyway. This could be particularly painful for maintenance when a change to an expression using
`=` needed to be changed to one using `eval` because, say, a string operator needed to be used. The conversion from one form to another isn't straightforward (i.e., it would be easy to forget to add every `$`' where needed).

So, right now, my hope is that _neither_ of these proposals is adopted.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> posted:

{=}{ ... } also seems NotRubbish to me on the same "regularity" factor I
was considering for rejecting the previously posted idea,

I was keen on the {=}{expression} form until I realised that it could only
be used as a separate word, it wouldn't work for a calculation embedded in
a string. Taking the same examples again:
set result {=}{$a + $b * $c}
would work, but
puts "Total: {=}{$sum + $tax}"
would not.
--
Colin Macleod ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ https://cmacleod.me.uk

FEED FEED FEED FEED FEED FEED FEED FEED
GAZA GAZA GAZA GAZA GAZA GAZA GAZA GAZA
NOW! NOW! NOW! NOW! NOW! NOW! NOW! NOW!
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Mark Summerfield <m.n.summerfield@gmail.com> posted:

I've looked again at the two competing proposals for an alternative to
the `[eval {rCa}]` syntax:

Clearly when you say `eval` you mean `expr`.

As for Tip 676, it doesn't appear to me to change the 12 rules, instead it introduces a new global function `=`. However, it also introduces a novel
DSL rather than using `eval`'s DSL. This seems to require a lot of
additional learning, particularly the dropping of the `$` for variable accesses, the fact that the string operators, `in`, `ni`, `eq`, `ne`, `lt`, `gt`, `le`, `ge` are not supported, the fact that `true` and `false` aren't supported, as well as the possible confusion over array accesses.

Reasonable points. I don't think it's possible to move forward in this
area without some tradeoffs.

particularly painful for maintenance when a change to an expression using
`=` needed to be changed to one using `eval` because, say, a string operator needed to be used. The conversion from one form to another isn't straightforward (i.e., it would be easy to forget to add every `$`' where needed).

If you leave out a `$` on a variable reference expr will complain "invalid bareword" so such a mistake will get reported as soon as you run it.
--
Colin Macleod ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ https://cmacleod.me.uk

FEED FEED FEED FEED FEED FEED FEED FEED
GAZA GAZA GAZA GAZA GAZA GAZA GAZA GAZA
NOW! NOW! NOW! NOW! NOW! NOW! NOW! NOW!
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 13/12/2025 11:51, Colin Macleod wrote:

Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> posted:

{=}{ ... } also seems NotRubbish to me on the same "regularity" factor I
was considering for rejecting the previously posted idea,

I was keen on the {=}{expression} form until I realised that it could only
be used as a separate word, it wouldn't work for a calculation embedded in
a string. Taking the same examples again:
set result {=}{$a + $b * $c}
would work, but
puts "Total: {=}{$sum + $tax}"
would not.

How would you fix:

puts "Totals: {*}{a b c}"

to write "Totals: a b c" ?

puts "Totals [some-string-conversion {*}list]"

so why not insert a generalisation of variable lookup that applies a
string conversion to any string. There's a handy incomplete
generalisation that's a painful wart that could be fixed around variable
names with braces in them, some variable names with $ and braces seem to
be unreferencable but I'm not organised enough to figure it out an example.

Maybe make it a macro form and always resolve to some {a b c}{d e f}
using whatever magic bits make it currently invalid:

puts "Totals ${magic1*magic2 procname parm1 ...magic3}{d e f}"
||
\/
puts "Totals [ procname parm1 ... {*}{d e f}]"

puts "Totals ${magic1magic2 procname parm1 ...magic3}{d e f}"
||
\/
puts "Totals [procname parm1 ... {d e f}]"

That will be quite generally useful if the magic1 magic2 and magic3 are
neat enough (perhaps some of them will turn out to be empty strings).

That's a choice to trade-off against fixing the invalid variable
references. It's very general but if you make [set "magic1wordmagic2wordsmagic3" value] run some specially registered
procedure then I think it might turn out very general in an okay way.

I think the magic's will involve ${ and } themselves because variables
called things like "${foo}" can't be referenced (at all easily, anyway): consider [puts "$${foo}"] and [puts "${${foo}}"] and all manner of quotings.

puts "Totals ${${procname parm1 ...}}{d e f}"
||
\/
puts "Totals [procname parm1 ... {d e f}]"

puts "Totals ${${- procname parm1 ...}}{*}{d e f}"
||
\/
puts "Totals [procname parm1 ... {*}{d e f}]"


That's something to consider the tradeoff against supporting variables
named ${} directly somehow that doesn't use a registered proc.
--
Tristan Wibberley

The message body is Copyright (C) 2025 Tristan Wibberley except
citations and quotations noted. All Rights Reserved except that you may,
of course, cite it academically giving credit to me, distribute it
verbatim as part of a usenet system or its archives, and use it to
promote my greatness and general superiority without misrepresentation
of my opinions other than my opinion of my greatness and general
superiority which you _may_ misrepresent. You definitely MAY NOT train
any production AI system with it but you may train experimental AI that
will only be used for evaluation of the AI methods it implements.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 13/12/2025 11:51, Colin Macleod wrote:

Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> posted:

{=}{ ... } also seems NotRubbish to me on the same "regularity" factor I
was considering for rejecting the previously posted idea,

I was keen on the {=}{expression} form until I realised that it could only
be used as a separate word, it wouldn't work for a calculation embedded in
a string. Taking the same examples again:
set result {=}{$a + $b * $c}
would work, but
puts "Total: {=}{$sum + $tax}"
would not.

What's the problem with

proc id {x} {return $x}
puts "Total: [id {=}{$sum + $tax}]"

or even

puts "Total: [approx {$sum + $tax}]"
--
Tristan Wibberley

The message body is Copyright (C) 2025 Tristan Wibberley except
citations and quotations noted. All Rights Reserved except that you may,
of course, cite it academically giving credit to me, distribute it
verbatim as part of a usenet system or its archives, and use it to
promote my greatness and general superiority without misrepresentation
of my opinions other than my opinion of my greatness and general
superiority which you _may_ misrepresent. You definitely MAY NOT train
any production AI system with it but you may train experimental AI that
will only be used for evaluation of the AI methods it implements.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 12/13/2025 1:28 AM, Mark Summerfield wrote:

I've looked again at the two competing proposals for an alternative to
the `[eval {rCa}]` syntax:

Current: set c [eval {sqrt($a**2 + $b**2)}]
Tip 672: set c $(sqrt($a**2 + $b**2))
Tip 676: set c [= sqrt(a**2 + b**2)]

I have a much more ambitious outlook for tcl expressions. I believe the $ substitution should be reserved for string substitution, not "contents of" as it is used in the (braced) expr command, where {$var op ...} has to be a number, not an arbitrary string. If used with an operator like, {$var+5} and var contains "10/2" then an error is thrown.

I see several ways that the = command can improve tcl. There are numerous commands that currently could benefit from "bare" variable arithmetic. For example,

foreach i [lseq 1 to n-1] {
...
}

The lseq command is currently using expr internally, and would require $n-1, but that is likely to be deprecated. One reason is injection problems. However, if it could instead of calling expr internally, call the = command, we could see safer, and cleaner syntax using bare variables.

The = proposal also fits right in with my suggestion of a 3+ arg [set] command, only now even simpler:

set disc = b**2 - 4*a*c

I'm sure there's a better way to do this (esp. at the C level), however this does work correctly,

rename ::set ::o_l_d_s_e_t
proc ::set {var args} {
if { [llength $args] <= 1 } {
uplevel 1 [list o_l_d_s_e_t $var {*}$args]
} else {
if { [lindex $args 0] ne "=" } {
error "set: Invalid 3+ arg operator: \"[lindex $args 0]\" should be \"=\""
}
uplevel 1 o_l_d_s_e_t $var [uplevel 1 = {*}[lrange $args 1 end]]
}
}

% set foo 100 ;# 1 or 2 args, unchanged
100
% set foo
100

But with 3 or more args:

% set foo = sqrt(foo)
10.0
% set foo = int(sqrt(foo)) + 100
103

There are many Tk commands, that take several arguments, that could eventually benefit,

.c create rectangle x y x+width y+height
.c create line x1 y1 x1+dx y1+dy x1+2*dx y1+2*dy
.c create oval cx-r cy-r cx+r cy+r
.c create polygon \
cx+r cy \
cx+r*0.5 cy+r*0.866 \
cx-r*0.5 cy+r*0.866

.c create arc x-size y-size x+size y+size -start angle-15 -extent 30

Compare this create arc with the currently required expr:

.c create arc [expr {$x - $size}] [expr {$y - $size}] \
[expr {$x + $size}] [expr {$y + $size}] \
-start [expr {$angle - 15}] -extent 30

One can get eyestrain trying to read the actual expressions!

List operations:

set val [lindex $list end-2*n+1]
set sublist [lrange $list n+1 end-n-1]

set list [lreplace $list end-2*count end-count {*}$newelems]
set list [linsert $list base+offset $item]

String operations:

set char [string index $str end-n]
set char [string index $str pos+offset]

set substr [string range $str start+skip end-trim]
set substr [string range $str end-2*n+1 end]

Many of these access their arguments using the Tcl_GetIntFromObj.

The Tk commands, mostly don't call these, but I recall one that did use Tcl_GetDoubleFromObj.

To leverage on these (from the idea in the withdrawn TIP 680) I inserted my own C numerical-only expression evaluator function, that allowed me to do many of the above but I still needed to use $var expansion to substitute down to purely numerical operands.

That was criticized for it's injection risk and so I never took it further. But otherwise it did work.

With bare variable support, the injection risk goes away, and we can have enhanced index expressions too. With similar modifications to the various Tk commands, we could see a lot simpler expression syntax there as well.

I'm looking at this as an opportunity to bring a whole new way of doing expression evaluation across much of Tcl/Tk. Then $ substitution would be used for string substitution, not just to indicate a variable in an expression.

However, these enhancements would not be from a single = TIP, but = could be the foundation for future TIPs.

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

Incidentally, in my fork of Colin's pure tcl prototype, I also implemented "functional" versions of [string length ...], [llength ...] and [lindex list index ?index ...?]. So, I can write (using the 3+ arg version of set),

% set string "string"
string
% set matrix [list [list 1 2] [list 3 4]]
{1 2} {3 4}
% set foo = llength(matrix) + strlen(string) + lindex(matrix,1,1)
12

These 3 were implemented directly with their equivalent bytecode commands. lindex is special, however, since it allows for a variable number of arguments. It uses the following table, of function vs. bytecode and number of args:

array set nativeFunc {
strlen {strlen 1}
llength {listLength 1}
lindex {lindexMulti -2}
xstrcat {strcat 2}
xtoupper {strcaseUpper 1}
xtolower {strcaseLower 1}
xstrindex {strindex 2}
xstrrange {strrange 3}
}

The x-functions are of dubious value for numerical expressions, but they work if not used in further calculations. The -2 indicates a variable arg list.

Eric
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 14/12/2025 01:04, et99 wrote:

On 12/13/2025 1:28 AM, Mark Summerfield wrote:

I've looked again at the two competing proposals for an alternative to
the `[eval {rCa}]` syntax:

Current: set c [eval {sqrt($a**2 + $b**2)}]
Tip 672: set c $(sqrt($a**2 + $b**2))
Tip 676: set c [= sqrt(a**2 + b**2)]

I have a much more ambitious outlook for tcl expressions. I believe the
$ substitution should be reserved for string substitution, not "contents
of" as it is used in the (braced) expr command, where {$var op ...} has
to be a number, not an arbitrary string.-a If used with an operator like, {$var+5} and var contains "10/2" then an error is thrown.

That's a really good reason to shy away from expr and choose a procedure
with a different name whose implemented DSL doesn't have $var for
references, but moving away from the founding scripting principle that
it's all about strings and their equivalents is a big deal.

Imagine if a scripter was using non-integers and the behaviour was not
as per their inspection of the variables.

Currently, Tcl makes that feel awkwardly special when you achieve it so
you feel the problems that follow are /your/ mistake. Languages that
don't do that require sophisticated diagnostic techniques and/or strong
type systems. That will be the consequence for Tcl. Such a change will
make for a very expensive time. It's a workmaker.

Better would be simple DSLs for the purpose of drafting from alternative habits:

numberish {
cmd1 arg arg $[x+1]
cmd2 arg arg $[y/x]
}

and because tcl is a stringly-typed language you can easily provide a
function that literally translates the numberish script to Tcl instead
of executing.


[large snip]

then example of handiness given by et99:

.c create arc x-size y-size x+size y+size -start angle-15
-extent 30

Compare this create arc with the currently required expr:

.c create arc [expr {$x - $size}] [expr {$y - $size}] \
[expr {$x + $size}] [expr {$y + $size}] \
-start [expr {$angle - 15}] -extent 30

You can fix that by something similar to quasi-quotation and you can
experiment until you find all the consequent problems of trying to
improve tcl until you decide it's a cruel thing to inflict on everyone:

numberish {
.c create arc !x-size !y-size !x+size !y+size !-start !angle-15 -extent 30
...
...
...
}

The nice thing about that solution is, because all large expressions are /obviously/ too difficult to do correctly instead of merely being
deceptively simple, no-one needs to try: they'll all go straight for the correct solution of breaking them up into many commands.


numberish -trace debugcallback {
...
...
}

will show why everyone has got it wrong all the time because no-one
likes built-in generic trace features for this sort of thing without Haskell-level type systems.

numberish -dbgid name {*}{-trace debugcallbackwrapper} -trace
programcallback {...}

will let people sed-in and sed-out debugging traces by adding {*}{-trace debugcallbackwrapper}


Eventually, once you've figured out all the problems, you have a
template for the right way to do it and can finally make a syntax change
to cement it for everyone to enjoy.


Where Tcl makes it difficult to implement numberish, fix that first. for example, Tcl should have an evaluation procedure that has hooks
sufficient for applying such enhancements. That will create the
experimental ecosystem necessary to derive syntax improvements without pain.
--
Tristan Wibberley

The message body is Copyright (C) 2025 Tristan Wibberley except
citations and quotations noted. All Rights Reserved except that you may,
of course, cite it academically giving credit to me, distribute it
verbatim as part of a usenet system or its archives, and use it to
promote my greatness and general superiority without misrepresentation
of my opinions other than my opinion of my greatness and general
superiority which you _may_ misrepresent. You definitely MAY NOT train
any production AI system with it but you may train experimental AI that
will only be used for evaluation of the AI methods it implements.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

I realise I've mixed multiple DSL ideas:


On 14/12/2025 03:28, Tristan Wibberley wrote:

numberish {
cmd1 arg arg $[x+1]
cmd2 arg arg $[y/x]
}

vs

numberish {
.c create arc !x-size !y-size !x+size !y+size !-start !angle-15 -extent 30 ...
...
...
}

I think I prefer the latter, it's one character to add in one place and
forces the programmer to more flat program expressions which forces more description, which causes better review, etc...

Obvs. it might need to be extended with a numberish namespace
eventually, then that extended with dynamic extent and so forth but it's
all just library stuff.
--
Tristan Wibberley

The message body is Copyright (C) 2025 Tristan Wibberley except
citations and quotations noted. All Rights Reserved except that you may,
of course, cite it academically giving credit to me, distribute it
verbatim as part of a usenet system or its archives, and use it to
promote my greatness and general superiority without misrepresentation
of my opinions other than my opinion of my greatness and general
superiority which you _may_ misrepresent. You definitely MAY NOT train
any production AI system with it but you may train experimental AI that
will only be used for evaluation of the AI methods it implements.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> posted:

What's the problem with

proc id {x} {return $x}
puts "Total: [id {=}{$sum + $tax}]"

or even

puts "Total: [approx {$sum + $tax}]"

The problem with these is that they have no advantage over just using:
puts "Total: [expr {$sum + $tax}]"
--
Colin Macleod ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ https://cmacleod.me.uk

FEED FEED FEED FEED FEED FEED FEED FEED
GAZA GAZA GAZA GAZA GAZA GAZA GAZA GAZA
NOW! NOW! NOW! NOW! NOW! NOW! NOW! NOW!
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 12/14/2025 3:40 AM, Tristan Wibberley wrote:

numberish {
.c create arc !x-size !y-size !x+size !y+size !-start !angle-15 -extent 30 >> ...
...
...
}

For a command that only accepts numerical arguments in the first 4 positions, why should one need to supply a sigil. The code already calls on a procedure to convert an argument to a pure number. Why not just go further and convert an expression argument to a number. And if it's simply a number, or the output of [expr...], well that will also work, so it's a compatible upgrade.

I'm going to assume you don't really need !-start, but once -start is seen, the next argument also needs to resolve to a number.

However you choose to do this, the = command is designed to do this transformation for you since it does the parsing and gets the values of the variables. If you use expr, you are at risk of exploits unless you brace and add $ sigils.

I'm not proposing that we change tcl all at once. The first step is to address the expr command for it's clutter and safety concerns when called internally. I'm supporting the = command as a foundation for future tcl improvements.

-et99





--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 12/14/2025 6:40 AM, Tristan Wibberley wrote:

I realise I've mixed multiple DSL ideas:

On 14/12/2025 03:28, Tristan Wibberley wrote:

numberish {
cmd1 arg arg $[x+1]
cmd2 arg arg $[y/x]
}

vs

numberish {
.c create arc !x-size !y-size !x+size !y+size !-start !angle-15 -extent 30 >> ...
...
...
}

Obvs. it might need to be extended with a numberish namespace

I lost the transition from rubberish to numberish :-)

Interesting thread. Working from the assumption that in any/all of the proposed approaches, both "x" as well as "$x" would be interpreted to
refer to the value of "x", I find it odd that one would be able to mix
"x" and "$x" references in the same statement line and be OK. One could imagine how an outsider, a newcomer or someone debugging some old code,
might approach this as some kind of magic trick that must be preserved
and replicated as-is and then told to others as a "Tcl-gotcha." And if
the new convention prevents "$x" from referring to the value of "x",
then we might need to add a few more rules to the language.

While it could work as a package or a module, I am not sure of the value
add, tbh.



--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

saito <saitology9@gmail.com> posted:

Interesting thread. Working from the assumption that in any/all of the proposed approaches, both "x" as well as "$x" would be interpreted to
refer to the value of "x", I find it odd that one would be able to mix
"x" and "$x" references in the same statement line and be OK.

This is analogous to how one can currently write:
[expr $x * 2]
or
[expr {$x * 2}]
In most cases either will work, but the second is safer and more efficient.

While it could work as a package or a module, I am not sure of the value add, tbh.

For my implementation of TIP 676, I have put the code in the core because
I did not want to duplicate all the definitions of math operators, their precedences and corresponding bytecodes which exist for `expr` but are
not made public; also because I want to byte-compile the command and that appears not to be practical for an extension.
--
Colin Macleod ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ https://cmacleod.me.uk

FEED FEED FEED FEED FEED FEED FEED FEED
GAZA GAZA GAZA GAZA GAZA GAZA GAZA GAZA
NOW! NOW! NOW! NOW! NOW! NOW! NOW! NOW!
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 14/12/2025 23:40, et99 wrote:

On 12/14/2025 3:40 AM, Tristan Wibberley wrote:

numberish {
.c create arc !x-size !y-size !x+size !y+size !-start !angle-15
-extent 30
...
...
...
}

For a command that only accepts numerical arguments in the first 4
positions, why should one need to supply a sigil.

I thought that was a problem you had with the notation you posted, that
there's no general way to express the calculation needed and the command
had its own language inside it.

I'm just elaborating the breadth of options for solution somewhat. The
idea above is a draft of a fairly nice flavour of alternatives for the
scale of concrete needs that had come up.

I'll carry on in case you agree that's valuable and important.

To give a general notation that's useful for tasks with small
calculations a short prefix sigil is valuable, and if a function for
larger expressions such that there must be whitespace has the same name
as the sigil then it's pretty good.

call numberish "qs!" (for "quasiscript !") or "qs=" (for "quasiscript
=") or qs# {for "quasiscript #"} and you've got yourself a good system
for scripting.

BTW I think "=" is the wrong symbol because its a common relation in mathematics rather than an evaluation, excel kind of got it wrong. But I
don't think its /terrible/. "#" might be better to indicate "a number approximated thusly:"

I'll carry on as if you agree '#' is best.

inside a qs# script every word beginning #, eg "#suffix" is interpreted
exactly as "[# suffix]" and "[# #suffix]" is interpreted as just
"#suffix" would be outside the qs# script so "##suffix" becomes, a
normal word "#suffix", passed through. The sigil is invalid as an
initial element of the expression DSL and immediately after the
expression DSL's open brackets unless it's doubled-up there:

##foo -> foo
#foo+bar -> value of foo plus value of bar
###foo reserved for some special quasiquote quasireference
#x+(#foo) reserved more generally
#x+(##foo) reserved for some special quasiquote quasireference


If your language for "proc '#'" works without spaces for short
expressions and has a useful grouping bracket choice ( so a
subexpression works here or there, then I think it's pretty good because
"qs# { cmd #x-(y+z) #top<bot }" is nice, quick and clear. then you can
convert between that and "cmd [# x - (y + z)] [# top < bot]" freely.

same applies if you stick with = instead of # or !. Thinking it over, #
is best, I think.

I'm not proposing that we change tcl all at once. The first step is to address the expr command for it's clutter and safety concerns when
called internally. I'm supporting the = command as a foundation for
future tcl improvements.

yes, expr is difficult. an alternative through which one can get started
in a similar manner is needed.

I think the use-case of lots of commands with small calculations from a
few variables is also of importance and the semantics and syntax of the
two should coincide usefully, generically, and intuitively.
--
Tristan Wibberley

The message body is Copyright (C) 2025 Tristan Wibberley except
citations and quotations noted. All Rights Reserved except that you may,
of course, cite it academically giving credit to me, distribute it
verbatim as part of a usenet system or its archives, and use it to
promote my greatness and general superiority without misrepresentation
of my opinions other than my opinion of my greatness and general
superiority which you _may_ misrepresent. You definitely MAY NOT train
any production AI system with it but you may train experimental AI that
will only be used for evaluation of the AI methods it implements.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 15/12/2025 02:49, saito wrote:

On 12/14/2025 6:40 AM, Tristan Wibberley wrote:

I realise I've mixed multiple DSL ideas:


On 14/12/2025 03:28, Tristan Wibberley wrote:

numberish {
-a-a cmd1 arg arg $[x+1]
-a-a cmd2 arg arg $[y/x]
}

vs

numberish {
.c create arc !x-size !y-size !x+size !y+size !-start !angle-15
-extent 30
...
...
...
}

Obvs. it might need to be extended with a numberish namespace

While it could work as a package or a module, I am not sure of the value
add, tbh.

well, we've already got commands with their own DSLs and special variables.

That's a big annoyance and a source of mistakes that a stringly-typed
scripting language can't afford.

The opportunity is here to ensure they're less warty as we go on which
my sigil-blocks/quasiscript-blocks don't handle right because I just
described them as mapping words directly to [...] equivalents and some
things like "end" need to be interpreted in the command the calculation
is for. (I think another sigil and its quasiscript-block interpreter
could be used to provide an evaluation delay - I will think more about it).

If a new expr-alternative is added it needs to be done so the DSL it
implements is compatible with the needs of quasiscripts such that the regularity of commands that take calculations as arguments can be
improved. Otherwise Tcl and its packages will just either get more warty
or stagnate rather than solidify into a good foundation.

I don't think it's a big challenge but requires a little thought up
front for the [= ...] or [# ...] or whatever to be a finished change.
--
Tristan Wibberley

The message body is Copyright (C) 2025 Tristan Wibberley except
citations and quotations noted. All Rights Reserved except that you may,
of course, cite it academically giving credit to me, distribute it
verbatim as part of a usenet system or its archives, and use it to
promote my greatness and general superiority without misrepresentation
of my opinions other than my opinion of my greatness and general
superiority which you _may_ misrepresent. You definitely MAY NOT train
any production AI system with it but you may train experimental AI that
will only be used for evaluation of the AI methods it implements.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> wrote:

BTW I think "=" is the wrong symbol because its a common relation in mathematics rather than an evaluation, excel kind of got it wrong. But I don't think its /terrible/. "#" might be better to indicate "a number approximated thusly:"

Unfortunately, while you are quite correct from a mathematics
viewpoint, that ship has long ago sailed for = meaning "evaluate
expression" in programming languages. Using = for "evaluate", while technically wrong mathematically, will fit with the built in
understanding anyone will have from programming languages as far back
as BASIC.

I'll carry on as if you agree '#' is best.

# is problematic because it is already used as the "commenting"
character, so overloading its usage to sometimes also mean "evaluate"
and the remainder mean "comment" would impose a new cognitive load upon readers and writers of code. They would have to disambiguate the two
meanings based on other contextual clues.

The = symbol, at least, has been mis-used to mean 'evaluate' for so
very long that there is no cognitive load for programmers seeing = in
code to have to disambiguate two very different meanings from context
clues. Only actual mathematicians will have some cognitive load in
seeing = used to mean evaluate.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 12/15/2025 4:18 AM, Colin Macleod wrote:

saito <saitology9@gmail.com> posted:

Interesting thread. Working from the assumption that in any/all of the
proposed approaches, both "x" as well as "$x" would be interpreted to
refer to the value of "x", I find it odd that one would be able to mix
"x" and "$x" references in the same statement line and be OK.

This is analogous to how one can currently write:
[expr $x * 2]
or
[expr {$x * 2}]
In most cases either will work, but the second is safer and more efficient.

My example tried to highlight the pitfalls of treating identically
different combinations of: x, "x", {x}, $x, and perhaps more. I think
this is quite different the semantics of using braces where you learn it
as a core part of Tcl.

A couple of thoughts:
Perhaps I am simply not using expr enough to see how annoying it could be.

Also consider Lua. I believe it started off as a fork of Tcl but I don't remember what the point of contention was. Perhaps this could be another approach. Fork a Better Tcl where "expr" doesn't exist.



--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 15/12/2025 16:09, Rich wrote:

Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> wrote:

Unfortunately, while you are quite correct from a mathematics
viewpoint, that ship has long ago sailed for = meaning "evaluate
expression" in programming languages. Using = for "evaluate", while technically wrong mathematically, will fit with the built in
understanding anyone will have from programming languages as far back
as BASIC.

tcl uses "set" for that and continues to do so. It is the last sanity remaining.

Haskell (correctly) uses <- and reserves = for a more nuanced definition concept, not for assignment or evaluation.

C uses = for assignment and not for evaluation.

I'll carry on as if you agree '#' is best.

# is problematic because it is already used as the "commenting"
character

Oh Crikey! That just didn't pop into my head! We wouldn't want that as a
sigil because we'd want to keep the space for the last word on a line to
become a comment someday.

The = symbol, at least, has been mis-used to mean 'evaluate' for so
very long that there is no cognitive load for programmers seeing = in
code to have to disambiguate two very different meanings from context
clues. Only actual mathematicians will have some cognitive load in
seeing = used to mean evaluate.

I've only seen it used to mean evaluate in BASIC and Excel. I don't
remember seeing it anywhere else.
--
Tristan Wibberley

The message body is Copyright (C) 2025 Tristan Wibberley except
citations and quotations noted. All Rights Reserved except that you may,
of course, cite it academically giving credit to me, distribute it
verbatim as part of a usenet system or its archives, and use it to
promote my greatness and general superiority without misrepresentation
of my opinions other than my opinion of my greatness and general
superiority which you _may_ misrepresent. You definitely MAY NOT train
any production AI system with it but you may train experimental AI that
will only be used for evaluation of the AI methods it implements.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 12/15/2025 4:08 PM, Tristan Wibberley wrote:

On 15/12/2025 16:09, Rich wrote:

The = symbol, at least, has been mis-used to mean 'evaluate' for so
very long that there is no cognitive load for programmers seeing = in
code to have to disambiguate two very different meanings from context
clues. Only actual mathematicians will have some cognitive load in
seeing = used to mean evaluate.

I've only seen it used to mean evaluate in BASIC and Excel. I don't
remember seeing it anywhere else.

I really like Colin's work is for it's educational value. Anyone truly interested in how expr and procedure compiling work should study his code. It is quite elegant and a demonstration of how the Tcl compiler system works.

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

As to the choice of command symbol:

The version of Colin's = written in pure tcl that I've enhanced uses : instead of the = as I've also implemented my own version of TIP 282 (multiple statements and an assignment operator). To my eyes, a multi-assignment statement that looked like this, seemed to suggest something was missing on the left side:

= a = b = c = 0

and so I prefer

: a = b = c = 0

I also use ' for an on the line statement separator, since the ; would need to be inside braces or the Tcl parser sees it first and abruptly ends the command. This let's me write this on 1 line without needing braces:

: a = 5 ' b = 2 ' a + b # returns 7 with a and b assigned their values

In addition, when one does use braces in a multi-statement multi-line command, it can handle blank lines, newline command separators, and comments starting with # or ;# like so, since it's done as a pre-parse pass:

: {

a = 10 ; b = 20
gather(a,b,max(a,b)) # as the last statement, returns a list as though [list $a $b [expr {max($a,$b)}]

}

where gather is

proc tcl::mathfunc::gather {args} {list {*}$args}


As a pure tcl extension, one is free to modify for one's uses.

However, for Tcl to grow into a more modern language, while still remaining true to it's core, I believe that Colin's C version should be approved for the entire community to benefit from out of the box.

And there's always rename and interp alias if one doesn't like the =

-et

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

I'm not sure it is a good idea to include single character function names in the base TCL set.
Things like:

proc a {...

are too useful at the command line.

For example I have my own take on a expr I call uexpr (it does math with units like ft sec kg watt ... etc).

package require uexpr

exposes the uexpr command at the global level.
There is an option in the uexpr pkgIndex.tcl for:

package require uexpr=

that aliases = to uexpr for convienence at the command line (= 3ft+6in=cm returns "106.68 cm")
However when I write a package "calc" to format calculations to generade .pdf files using pdflatex
and uexpr, I require uexpr, and use the canonical uexpr name in the package code
because the = alias might be preempted for some other purpose at the command line.

I think single character command names are too useful at the command line to be "taken" by the base TCL language or a widely used package.

daveb

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

The message body is Copyright (C) 2025 Tristan Wibberley except
citations and quotations noted. All Rights Reserved except as noted in
the sig.

On 15/12/2025 18:12, saito wrote:

On 12/15/2025 4:18 AM, Colin Macleod wrote:

saito <saitology9@gmail.com> posted:

Interesting thread. Working from the assumption that in any/all of the
proposed approaches, both "x" as well as "$x" would be interpreted to
refer to the value of "x", I find it odd that one would be able to mix
"x" and "$x" references in the same statement line and be OK.

This is analogous to how one can currently write:
-a-a [expr $x * 2]
or
-a-a [expr {$x * 2}]
In most cases either will work, but the second is safer and more
efficient.

My example tried to highlight the pitfalls of treating identically
different combinations of: x, "x", {x}, $x, and perhaps more. I think
this is quite different the semantics of using braces where you learn it
as a core part of Tcl.

I'm now thinking about those places like lindex where an argument is
end-2 and stuff like that.

That's a DSL that could do with being generalised. It /must/ be at least partially deferred to interpret at least some names in a dynamic closure
inside the command it's passed to. It suffers from the problem that it's
not /generally/ obvious what DSL it is. It already uses some names
without $ that act like object references yet it's common to expand
variables into the expression using text, even though the expansion is
into a word so it may be an expression segment rather than an object representation. There are many factors that make it ripe for
generalisation with a sigil in a sigil-designated block of code (a quasiscript). Fortunately that can be done in a package to experiment
and get it right.

Regarding your concern about why there are various ways to use a variable:

see man tcl if on linux and read and understand the 12 rules in details, experiment based on what you find there.

{} quotes whitespace and prevents commands in [] or variable references
eg $x, from being substituted
"" quotes whitespace but /doesn't/ prevent ...
each might have other effects besides, see man tcl.


x - a letter, can be interpreted by a command
any way the command specifies, including
as a variable reference
"x" - a letter, see above
{x} - a letter, see above
{{x}} - word that's a brace, letter, brace sequence
"{x}" - same
$x - a word from a tcl variable called x
"$x" - a word from a tcl variable called x, the
different notation is just about allowing
spaces into the word around $x but this
example does not take advantage of that
(see "a ${x} b" below)
a${x}b - a string starting a, ending b, with the
string from a tcl variable called x pasted
in the middle.
"a${x}"b" - same
"a ${x} b" - same but with spaces in the resulting word
{$x} - a word that's a dollar followed by an x, can
be interpreted by a command any way the
command specifies
{a $x b} - string starting a, ending b, dollar followed
by x in the middle, some spaces around it,
can be interpreted by a command any way the
command specifies
a{b - a word starting a, ending b, with a brace in the middle
--
Tristan Wibberley

The message body is Copyright (C) 2025 Tristan Wibberley except
citations and quotations noted. All Rights Reserved except that you may,
of course, cite it academically giving credit to me, distribute it
verbatim as part of a usenet system or its archives, and use it to
promote my greatness and general superiority without misrepresentation
of my opinions other than my opinion of my greatness and general
superiority which you _may_ misrepresent. You definitely MAY NOT train
any production AI system with it but you may train experimental AI that
will only be used for evaluation of the AI methods it implements.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> posted:

I'm now thinking about those places like lindex where an argument is
end-2 and stuff like that.

That's a DSL that could do with being generalised.

In the Discussion section of TIP 676 I said:

Some of the string and list-related commands already support a restricted
form of numeric expressions for indices, e.g. [lindex $list end-2]. This
could be generalised in future by having them temporarily define end as
the appropriate value and run the = processing on index arguments.
--
Colin Macleod ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ https://cmacleod.me.uk

FEED FEED FEED FEED FEED FEED FEED FEED
GAZA GAZA GAZA GAZA GAZA GAZA GAZA GAZA
NOW! NOW! NOW! NOW! NOW! NOW! NOW! NOW!
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 12/16/2025 4:11 AM, Tristan Wibberley wrote:

The message body is Copyright (C) 2025 Tristan Wibberley except
citations and quotations noted. All Rights Reserved except as noted in
the sig.

What does that mean?

Regarding your concern about why there are various ways to use a variable:

see man tcl if on linux and read and understand the 12 rules in details, experiment based on what you find there.

I suspect you missed the point of the message. While there are Tcl
commands that currently accept a variable name or a variable value, you
cannot mix and match them willy-nilly. But the proposed solutions would, AFAICT, allow one to write "x + $x" to end up with a value of 2*x. That
is something I have not seen elsewhere and may end up doing more harm
than good.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 16/12/2025 14:17, Colin Macleod wrote:

Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> posted:

I'm now thinking about those places like lindex where an argument is
end-2 and stuff like that.

That's a DSL that could do with being generalised.

In the Discussion section of TIP 676 I said:

Some of the string and list-related commands already support a restricted
form of numeric expressions for indices, e.g. [lindex $list end-2]. This
could be generalised in future by having them temporarily define end as
the appropriate value and run the = processing on index arguments.

That's a mere implementation choice, though, I feel it should be somehow present in the user experience such as with a sigil. I'm currently
sleeping on it, how to make a very general system with the right properties.

[] doesn't look okay because (a) it requires clumsy cursor moving, and
(b) it is not deferred. obvious deferring method {[= end-1]} feels like
too much to type but it does look good as an idiom.

Maybe it's okay because when you do it a lot, a quasiscript block will
let you use a sigil instead for equivalent functionality but happier
inputting and the quasiscript block will be implementable as just
another library feature that rewrites a script to long form.

lindex $l {[= end-1]}

This is an obvious pattern that can eventually be taken to be regular.
and it can be supported in such commands by literally failing to parse
the old format then falling back to merely executing [undefer 2 {{var
value} ...} $expression]. 'undefer' might itself be a complication of
'proc {level vars expression} { uplevel $levels withvars $vars return $expression }' to get the right dynamic closure but it also cries out
for some sort of standardised structured error callback especially so quasiscripts can patch the error elements to undo their rewrites.

.c create somewidget {[= left+10]} {[= right-10]} ...

set myshorts {{l left} {r right}}
qs= $myshorts -- .c create somewidget =l+10 =r-10 ...


qs= {{l left} {r right}} -- {
.c create somewidget =l+10 ...
.c create somewidget =l+20 ...
.c create somewidget =r-10 ...
}

there is a need to specify compound relations and apply a solver from
time to time (even for simple layout things, or especially), all deferred.

I think it can be supported with the above form. I wonder how to handle
errors - the expression will be slightly different at execution time
than in the script.

Still, I think = is the wrong symbol.
--
Tristan Wibberley

The message body is Copyright (C) 2025 Tristan Wibberley except
citations and quotations noted. All Rights Reserved except that you may,
of course, cite it academically giving credit to me, distribute it
verbatim as part of a usenet system or its archives, and use it to
promote my greatness and general superiority without misrepresentation
of my opinions other than my opinion of my greatness and general
superiority which you _may_ misrepresent. You definitely MAY NOT train
any production AI system with it but you may train experimental AI that
will only be used for evaluation of the AI methods it implements.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

The message body is Copyright (C) 2025 Tristan Wibberley except
citations and quotations noted. All Rights Reserved except as noted in
the sig.

On 16/12/2025 16:39, saito wrote:

While there are Tcl
commands that currently accept a variable name or a variable value, you cannot mix and match them willy-nilly. But the proposed solutions would, AFAICT, allow one to write "x + $x" to end up with a value of 2*x. That
is something I have not seen elsewhere and may end up doing more harm
than good.

I agree.

I just posted elsewhere to this thread a fairly general deferred
expression method that only uses barewords for variable references (call
them "free indeterminates" from the perspective of the expression, or
perhaps you can get away with "context-bound indeterminates" from the perspective of the point of their eventual evaluation without any prefix
being added to bind them to Tcl variables).
--
Tristan Wibberley

The message body is Copyright (C) 2025 Tristan Wibberley except
citations and quotations noted. All Rights Reserved except that you may,
of course, cite it academically giving credit to me, distribute it
verbatim as part of a usenet system or its archives, and use it to
promote my greatness and general superiority without misrepresentation
of my opinions other than my opinion of my greatness and general
superiority which you _may_ misrepresent. You definitely MAY NOT train
any production AI system with it but you may train experimental AI that
will only be used for evaluation of the AI methods it implements.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 12/15/2025 9:59 PM, clt.to.davebr@dfgh.net wrote:

I'm not sure it is a good idea to include single character function names in the base TCL set.
Things like:

proc a {...

are too useful at the command line.

For example I have my own take on a expr I call uexpr (it does math with units like ft sec kg watt ... etc).

package require uexpr

exposes the uexpr command at the global level.
There is an option in the uexpr pkgIndex.tcl for:

package require uexpr=

that aliases = to uexpr for convienence at the command line (= 3ft+6in=cm returns "106.68 cm")
However when I write a package "calc" to format calculations to generade .pdf files using pdflatex
and uexpr, I require uexpr, and use the canonical uexpr name in the package code
because the = alias might be preempted for some other purpose at the command line.

I think single character command names are too useful at the command line to be "taken" by the base TCL language or a widely used package.

daveb

This is a valid concern. It is at least as valid as the main objection to $(...) that of colliding with the invisible array name.

I suppose to be fully compatible, = would need to be defined in a namespace. =::= comes to mind, but that's likely as bad on the eyes as a cluttered expr command.

I would think that any package developer with their own namespace could import = into it, but only the top level app developer would likely have the freedom to import into the global namespace.

I hadn't given it much thought before, but my choice of : may be better or worse in this regard, since I'm not even sure how one would encode it into a namespace. AFAIK, extra : characters, as in ::::aglobal are allowed and the extra pair ignored. But what about an odd number. Can I have ::ns::: as the name : inside namespace ns?

I guess any new command can cause a problem. When I wrote up the TIP that became lseq, I wanted to call it range, since it was to implement the python range function in Tcl. I realized it was likely to collide, so I then suggested rangeof, especially since it would be used a lot with foreach. So, foreach i [rangeof ...] seemed to run smoothly. We ended up with lseq so it could begin with an l, and seq since it was implemented as a sequence, not a true list.

Changing Tcl is really hard to do and keep everyone happy.

-et

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 12/16/2025 6:17 AM, Colin Macleod wrote:

Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> posted:

I'm now thinking about those places like lindex where an argument is
end-2 and stuff like that.

That's a DSL that could do with being generalised.

In the Discussion section of TIP 676 I said:

Some of the string and list-related commands already support a restricted
form of numeric expressions for indices, e.g. [lindex $list end-2]. This
could be generalised in future by having them temporarily define end as
the appropriate value and run the = processing on index arguments.

When I worked on modified index expressions (using my numerical expression C function) I had to address the end issue. I still don't fully understand how end is encoded, but I originally thought that end was always the same as list/string length - 1. But that's not the case. Some commands treat end differently, such as linsert. If you look at the coding of an index in GetEndOffsetFromObj you will see how end is done.

I may be wrong, but I believe the reason for this is so the caller can decide how to use end in a calculation. I did eventually get it to work, but that was long enough ago that I've now forgotten how it works, just that it was very confusing to me at the time.

-et

--- Synchronet 3.21a-Linux NewsLink 1.2