tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] TIP 732 ready for comments

[Marc C. <cul...@gm...>]

It is not clear to me from the TIP what the default search path would be
for macOS.  However, macOS is not a single platform in this context.  It
can be built two ways:
(1) a framework build, which installs in /Library/Frameworks/Tcl.framework
(and an analogous Library/Frameworks/Tk.framework.
(2) a "prefix" build, which installs in <prefix>/{bin,lib.include,share}

In the past the default search path accommodated both build types.

For a framework build of Tcl X.Y, init.tcl was installed in:
/Library/Frameworks/Tcl.framework/Versions/X.Y/Resources/Scripts/
and that was also a place where third party packages could be installed.
(By the way this is a good way to handle different versions of Tcl and Tk.)

For a prefix build I believe that the install policy was the same as for
other unix systems.

However, other directories were included in the search path on macOS.
These included /Library/Tcl and / or /Library/Tcl/X.Y.  In addition there
was a notion that a user might install a Tcl.framework in their personal
Library directory.  So another location was
$HOME/Library/Frameworks/Tcl.framework/Versions/X.Y/Resources/Scripts.

Incidentally Apple's (flexible) rules for how files should be arranged in a
framework specify that executable scripts should go in the Resources
directory.  However this conflicts with the fact that while some extension
packages contain only scripts, others contain dynamic libraries.  However,
there seems to be no problem with installing a package that has a dynamic
library into
/Library/Frameworks/Tcl.framework/Versions/X.Y/Resources/Scriopts.

- Marc

On Mon, Nov 3, 2025 at 4:29 AM Jan Nijtmans <jan...@gm...> wrote:

> Op zo 2 nov 2025 om 08:35 schreef apnmbx-public:
> >
> > TIP 732: Changes to the Tcl script library search path is ready for
> comments.
> ....
> > I’m particularly interested in feedback from Unix and macOS folks that
> build distributions if this impacts them in any way.
>
> Well, I like this TIP, but there is a test failure on MacOS:
>     <https://github.com/tcltk/tcl/actions/runs/18965835171/job/54162420957
> >
>
> ==== unixInit-3.2 TclpSetInitialEncodings FAILED
> ==== Contents of test case:
> set env(LANG) japanese
> set env(LC_ALL) japanese
> set f [open "|[list [interpreter]]" w+]
> chan configure $f -buffering none
> puts $f {puts [encoding system]; exit}
> set enc [gets $f]
> close $f
> set enc
> ---- Test generated error; Return code was: 1
> ---- Return code should have been one of: 0 2
> ---- errorInfo: application-specific initialization failed: Cannot
> find a usable init.tcl in the following directories:
> /Users/runner/work/tcl/tcl/lib/tcl9.1
> This probably means that Tcl wasn't installed properly.
> while executing
> "close $f"
> ("uplevel" body line 8)
> invoked from within
> "uplevel 1 $script"
> ---- errorCode: NONE
> ==== unixInit-3.2 FAILED
>
> Hope this helps,
>       Jan Nijtmans
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

Re: [TCLCORE] TIP 732 ready for comments

[Jan N. <jan...@gm...>]

Op zo 2 nov 2025 om 08:35 schreef apnmbx-public:
>
> TIP 732: Changes to the Tcl script library search path is ready for comments.
....
> I’m particularly interested in feedback from Unix and macOS folks that build distributions if this impacts them in any way.

Well, I like this TIP, but there is a test failure on MacOS:
    <https://github.com/tcltk/tcl/actions/runs/18965835171/job/54162420957>

==== unixInit-3.2 TclpSetInitialEncodings FAILED
==== Contents of test case:
set env(LANG) japanese
set env(LC_ALL) japanese
set f [open "|[list [interpreter]]" w+]
chan configure $f -buffering none
puts $f {puts [encoding system]; exit}
set enc [gets $f]
close $f
set enc
---- Test generated error; Return code was: 1
---- Return code should have been one of: 0 2
---- errorInfo: application-specific initialization failed: Cannot
find a usable init.tcl in the following directories:
/Users/runner/work/tcl/tcl/lib/tcl9.1
This probably means that Tcl wasn't installed properly.
while executing
"close $f"
("uplevel" body line 8)
invoked from within
"uplevel 1 $script"
---- errorCode: NONE
==== unixInit-3.2 FAILED

Hope this helps,
      Jan Nijtmans

Re: [TCLCORE] Fwd: TIP 672 Implementation Complete - Ready for Sponsorship

[Donal F. <don...@ma...>]

Doing the job properly would definitely involve changing the expression parser, with my suggested fix being to turn all bare words not otherwise recognised as constants or in positions that look like function calls (it's a parser with some lookahead) into simple variable reads (NB: C resolves such ambiguities within itself differently, but that's one of the nastiest parts of the language). We would need to retain $ support for resolving ambiguity (e.g., array reads vs function calls; you can't safely inspect the interpreter to resolve it at the time of compiling the expression due to traces and unknown handlers) as well as compatibility, but that's doable as it is a change only in cases that are currently errors.

Adding assignment is quite a bit trickier, as that needs a new major syntax class to describe the left side of the assignment. I suggest omitting that from consideration at this stage.

Donal.

-------- Original message --------
From: Colin Macleod via Tcl-Core <tcl...@li...>
Date: 02/11/2025 08:13 (GMT+00:00)
To: Pietro Cerutti <ga...@ga...>
Cc: tcl...@li..., av...@lo...
Subject: Re: [TCLCORE] Fwd: TIP 672 Implementation Complete - Ready for Sponsorship


Indeed, this toy implementation doesn't handle that:

% = sin (12)
can't read "sin": no such variable

I'm not sure that's serious, but it could be fixed in a C implementation.

Re: [TCLCORE] ***CAUTION_Invalid_Partial_Signature*** [Ext] Re: Fwd: TIP 672 Implementation Complete - Ready for Sponsorship

[Colin M. <col...@ya...>]

The updated prototype I posted yesterday handles this.

On 03/11/2025 07:19, Zaumseil René wrote:
>
> Just do a "string map {{ } {}} .." at first.
>
> *Von:*Pietro Cerutti via Tcl-Core <tcl...@li...>
> *Gesendet:* Sonntag, 2. November 2025 09:05
> *An:* Colin Macleod <col...@ya...>
> *Cc:* tcl...@li...; av...@lo...
> *Betreff:* ***CAUTION_Invalid_Partial_Signature*** [Ext] Re: [TCLCORE] 
> Fwd: TIP 672 Implementation Complete - Ready for Sponsorship
>
> How does it handle a space between a mathfunc and its parenthesized 
> argument list?
>
> % expr {sin (12)}
>
> -0.5365729180004349
>
> -- 
>
> Pietro Cerutti
>
> I've pledged to give 10% of income to effective charities and invite 
> you to join me.
>
> https://givingwhatwecan.org
>
> Sent from a small device - please excuse brevity and typos.
>
>
>
>     On 1 Nov 2025, at 17:50, Colin Macleod via Tcl-Core
>     <tcl...@li...> wrote:
>
>     
>
>     On 30/10/2025 01:18, Andreas Leitgeb wrote:
>
>            - [= ...] with a modified expr-language using barewords as variable
>
>              names would probably solve many (if not most) of the cases, where
>
>              [expr {...}] really "hurts" for its verbosity.
>
>     Here is a pure Tcl implementation of that:
>
>         proc = args {
>             set ex [join $args]
>             set exp [regsub -all
>         {(::)?[[:alpha:]]([[:alnum:]_]|::)*([^[:alnum:]_(]|$)} $ex {$&}]
>             uplevel expr $exp
>         }
>
>     This just finds all the possible variable names in the expression,
>     prefixes them with $ and then runs expr on the result.  The regex
>     is a little complicated because:
>
>       * The variable name could include :: at the beginning or in the
>         middle for namespacing.
>       * We disallow single colon : within the name because that
>         creates ambiguity with the ternary operator ?: .
>       * We also disallow array references because we can't distinguish
>         them from mathfunc calls.
>
>     The fact that this can be implemented in pure Tcl shows that it
>     doesn't require any change to the dodekalogue rules, and so there
>     is no consequence for subst either.
>
>     Of course a real implementation should be done in C.  It could
>     then also be possible to implement the extension Kevin Kenny
>     suggested of adding `=` as an assignment operator as in C within
>     an expression, and perhaps even chaining multiple assignments with
>     `,` .
>
>     I saw the `expr` question is on the agenda for the call on
>     Monday.  I don't usually join these calls but I would join it for
>     this issue except that I have an urgent dentist's appointment at
>     that time.  Perhaps I should create a new TIP for this proposal?
>
>     Colin.
>
>     _______________________________________________
>     Tcl-Core mailing list
>     Tcl...@li...
>     https://lists.sourceforge.net/lists/listinfo/tcl-core
>

Re: [TCLCORE] ***CAUTION_Invalid_Partial_Signature*** [Ext] Re: Fwd: TIP 672 Implementation Complete - Ready for Sponsorship

[Zaumseil R. <RZa...@kk...>]

Just do a "string map {{ } {}} .." at first.

Von: Pietro Cerutti via Tcl-Core <tcl...@li...>
Gesendet: Sonntag, 2. November 2025 09:05
An: Colin Macleod <col...@ya...>
Cc: tcl...@li...; av...@lo...
Betreff: ***CAUTION_Invalid_Partial_Signature*** [Ext] Re: [TCLCORE] Fwd: TIP 672 Implementation Complete - Ready for Sponsorship

How does it handle a space between a mathfunc and its parenthesized argument list?

% expr {sin (12)}
-0.5365729180004349

--
Pietro Cerutti
I've pledged to give 10% of income to effective charities and invite you to join me.
https://givingwhatwecan.org

Sent from a small device - please excuse brevity and typos.



On 1 Nov 2025, at 17:50, Colin Macleod via Tcl-Core <tcl...@li...<mailto:tcl...@li...>> wrote:

On 30/10/2025 01:18, Andreas Leitgeb wrote:

  - [= ...] with a modified expr-language using barewords as variable

    names would probably solve many (if not most) of the cases, where

    [expr {...}] really "hurts" for its verbosity.

Here is a pure Tcl implementation of that:

proc = args {
    set ex [join $args]
    set exp [regsub -all {(::)?[[:alpha:]]([[:alnum:]_]|::)*([^[:alnum:]_(]|$)} $ex {$&}]
    uplevel expr $exp
}

This just finds all the possible variable names in the expression, prefixes them with $ and then runs expr on the result.  The regex is a little complicated because:

  *   The variable name could include :: at the beginning or in the middle for namespacing.
  *   We disallow single colon : within the name because that creates ambiguity with the ternary operator ?: .
  *   We also disallow array references because we can't distinguish them from mathfunc calls.

The fact that this can be implemented in pure Tcl shows that it doesn't require any change to the dodekalogue rules, and so there is no consequence for subst either.

Of course a real implementation should be done in C.  It could then also be possible to implement the extension Kevin Kenny suggested of adding `=` as an assignment operator as in C within an expression, and perhaps even chaining multiple assignments with `,` .

I saw the `expr` question is on the agenda for the call on Monday.  I don't usually join these calls but I would join it for this issue except that I have an urgent dentist's appointment at that time.  Perhaps I should create a new TIP for this proposal?

Colin.
_______________________________________________
Tcl-Core mailing list
Tcl...@li...<mailto:Tcl...@li...>
https://lists.sourceforge.net/lists/listinfo/tcl-core

[TCLCORE] TIP 672 prototype Compiler issue fixed - functional for evaluation

[EricT <tw...@gm...>]

Hi Tcl Core team,

Following up on my earlier email about the array subscript limitation:
I've found and fixed the compiler issue. The prototype is now
functional again for evaluation purposes, though the line number
tracking issue I mentioned earlier remains.

The Fix (this is not posted anywhere else - just an old/new below):

The problem was in TclPushVarName (tclCompile.c), which uses pointer
arithmetic between adjacent tokens to calculate array index lengths.
For x($((expr))), the tokens are:
- Token[1]: TEXT "x(" in original source
- Token[2]: COMMAND "[expr {...}]" in synthetic buffer
- Token[3]: TEXT ")" in original source

When the code calculated varTokenPtr[2].start - p, it was subtracting
pointers from different memory allocations, producing garbage values.

The fix avoids cross-token pointer arithmetic by staying within single
tokens and summing token sizes instead:

Here's the context, followed by the OLD to be replaced with the NEW


    /*
     * Check the last token: if it is just ')', do not count it.
     * Otherwise, remove the ')' and flag so that it is restored at
     * the end.
     */

    if (varTokenPtr[n].size == 1) {
        n--;
    } else {
        varTokenPtr[n].size--;
        removedParen = n;
    }

    name = varTokenPtr[1].start;
    nameLen = p - varTokenPtr[1].start;
    elName = p + 1;

// OLD (broken):
    remainingLen = (varTokenPtr[2].start - p) - 1;
    elNameLen = (varTokenPtr[n].start - p) + varTokenPtr[n].size - 1;

// NEW (fixed):
    remainingLen = (varTokenPtr[1].start + varTokenPtr[1].size) - (p + 1);
    elNameLen = remainingLen;
    for (Tcl_Size i = 2; i <= n; i++) {
        elNameLen += varTokenPtr[i].size;
    }

What these calculate:

When parsing x(abc$var), the code needs to extract the array index portion:

- remainingLen: Length of literal text after ( in the first token
("abc" = 3 bytes). Used to set the size of a newly created TEXT token
for that fragment inserted before any following tokens. The fix now
correctly computes this by staying within varTokenPtr[1]'s buffer.

- elNameLen: Total array index length. Currently only used to check if
the index is empty (zero vs non-zero):

    if (elNameLen) {
        TclCompileTokens(interp, elemTokenPtr, elemTokenCount, envPtr);
    } else {
        PUSH("");  // Empty array index
    }

Note: The fix sums token sizes, which for expression substitution
includes the synthetic buffer size (12 bytes for "[expr {1+2}]")
rather than the original source size (8 bytes for "$((1+2))"). This
doesn't affect the current zero/non-zero check, but future maintainers
would have to be aware that elNameLen represents token sizes, not
original source length.

However, as mentioned, for production code, it would be better to
engineer this into the parser with a new token type which specifically
is intended for synthetic strings. This could also be used for other
purposes, so it might not be just a single use token. And it should
also be tracked for later deletion when it is no longer in use,
possibly if there's a new compiler epoch.

Status:

Array subscripts will now work correctly with the synthetic string
approach. The prototype can be used for community evaluation of
whether $((...)) syntax is useful enough to include in Tcl 9.1.

The line number tracking issue remains, but that's a separate problem
affecting error reporting rather than functionality.

Best regards,
Eric

Re: [TCLCORE] TIP 561 - Working console.tcl implementation with channel transforms

[<apn...@ya...>]

Thanks, Eric.

 

Will merge later today.

 

/Ashok

 

From: EricT <tw...@gm...> 
Sent: Sunday, November 2, 2025 2:55 PM
To: apn...@ya...
Cc: tc...@ro...; Tcl...@li...
Subject: Re: [TCLCORE] TIP 561 - Working console.tcl implementation with channel transforms

 

Subject: Re: TIP 561 - Dynamic encoding fix and other updates

Ashok,

You're absolutely right - hardcoding UTF-8 was an oversight. Thank you for catching that!

I've updated the transform to query the channel's encoding dynamically:

    # Get the channel's actual encoding instead of hardcoding UTF-8
    set enc [fconfigure $what -encoding]
    if {$enc ne "binary"} {
        set data [encoding convertfrom $enc $data]
    }

I'm not entirely sure how to test different encodings in practice, but the change didn't break anything and the logic is clearly more correct.

I've also made several other improvements based on testing:

1. Removed the pre-8.6 puts wrapper code entirely (targeted for Tcl 9.1+)
2. Fixed console show/hide cycling so the console can be closed and reopened multiple times
3. The console command now properly manages channel transforms on hide/show
4. Changed window close from "destroy" to "wm withdraw" for reopening capability


The updated code is at: https://github.com/rocketship88/tcl-console-unix

When convenient, it would be great to get this merged into the TIP 561 branch. I appreciate it being on Tuesday's agenda, though unfortunately I won't be able to attend (4 AM my time, and no mic/camera). I may try to lurk if I'm awake.

Thank you,
Eric

 

On Sun, Nov 2, 2025 at 1:07 AM apnmbx-public--- via Tcl-Core <tcl...@li... <mailto:tcl...@li...> > wrote:

Eric,

 

I believe (but not completely sure) that the bytes are not always UTF-8 encoded but rather encoded as per the channel’s configuration. So decoding should probably be done using whatever encoding has been configured for the channel.

 

/Ashok 

 

From: EricT <tw...@gm... <mailto:tw...@gm...> > 
Sent: Saturday, November 1, 2025 3:14 AM
To: Tcl...@li... <mailto:Tcl...@li...> 
Subject: [TCLCORE] TIP 561 - Working console.tcl implementation with channel transforms

 

Hello Tcl Core Team,

I've successfully resolved the Unicode handling issues with the channel transform 
implementation for TIP 561 (Console command for Linux/Unix).

The key fix was recognizing that channel transforms receive UTF-8 encoded bytes, 
which need to be decoded back to Unicode strings before passing to the Tk console 
widget:

    set data [encoding convertfrom utf-8 $data]

This eliminates the need for the pre-8.6 puts wrapper method, providing a clean, 
API-based solution using TIP#230 channel transforms.

The working implementation is available at:

https://github.com/rocketship88/tcl-console-unix

Since I don't have permissions to update the TIP or its branch, could someone 
kindly review the code and update console.tcl in the TIP 561 repository if it 
looks acceptable?

The implementation has been tested on Pop!_OS Linux with proper Unicode display, 
console cleanup, and output restoration to the terminal.

Thank you,
Eric

_______________________________________________
Tcl-Core mailing list
Tcl...@li... <mailto:Tcl...@li...> 
https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] Fwd: TIP 672 Implementation Complete - Ready for Sponsorship

[EricT <tw...@gm...>]

Hi Florent:

> Personnally, I'm not disturbed by the '$' sign, I'm very used to it. When
> I see a '$' in Tcl, I think immediately : variable.
>

Interestingly, I always think of $ as "contents of", sort of like in C with
char *s; s is the variable, *s gets you the contents.  In Tcl, we sometimes
pass the contents of a variable using $var, but other times we pass the
name with just var, as in [set var] or [lappend var ...].  I guess it's
where you've come from that affects your thinking.

Eric

Re: [TCLCORE] CFV: TIP 733, Add accessibility/screen reader support to Tk

[Harald O. <har...@el...>]

Am 02.11.2025 um 01:36 schrieb Kevin Walzer:
> Hi all,
> 
> I've had no additional feedback on TIP 733 in the past week, and I 
> believe the tka11y branch is ready for merging, so I'd like to call for 
> a TCT vote.
> 
> Let's have votes in by [clock format 1762559940 -gmt 1].
> 
> My vote: TIP 733: YES
+1 !
Great work, Kevin !

Tahnks for all,
Harald

Re: [TCLCORE] Fwd: TIP 672 Implementation Complete - Ready for Sponsorship

[Colin M. <col...@ya...>]

Hi again,

I've now made a slightly more serious prototype, see 
https://cmacleod.me.uk/tcl/expr_ng

This is a modified version of the prototype I wrote for tip 676. It's 
still in Tcl, but doesn't use `expr`.  It tokenises and parses the 
input, then generates TAL bytecode and uses ::tcl::unsupported::assemble 
to run that.  A few examples:

    (bin) 100 % set a [= 3.0/4]
    0.75
    (bin) 101 % set b [= sin(a*10)]
    0.9379999767747389
    (bin) 102 % set c [= (b-a)*100]
    18.79999767747389
    (bin) 103 % namespace eval nn {set d [= 10**3]}
    1000
    (bin) 104 % set e [= a?nn::d:b]
    1000
    (bin) 105 % = {3 + [pwd]}
    Calc: expected start of expression but found '[pwd]'
    (bin) 106 % = {3 + $q}
    Calc: expected start of expression but found '$q'
    (bin) 107 % = sin (12)
    -0.5365729180004349

    (bin) 108 % array set rr {one 1 two 2 three 3}
    (bin) 110 % = a * rr(two)
    Calc: expected operator but found '('
    (bin) 111 % = a * $rr(two)
    1.5

- You can use $ to get an array value substituted before the `=` code 
sees the expression.

    (bin) 112 % string repeat ! [= nn::d / 15]
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Colin.

On 02/11/2025 09:04, Donal Fellows wrote:
> Doing the job properly would definitely involve changing the 
> expression parser, with my suggested fix being to turn all bare words 
> not otherwise recognised as constants or in positions that look like 
> function calls (it's a parser with some lookahead) into simple 
> variable reads (NB: C resolves such ambiguities within itself 
> differently, but that's one of the nastiest parts of the language). We 
> would need to retain $ support for resolving ambiguity (e.g., array 
> reads vs function calls; you can't safely inspect the interpreter to 
> resolve it at the time of compiling the expression due to traces and 
> unknown handlers) as well as compatibility, but that's doable as it is 
> a change only in cases that are currently errors.
>
> Adding assignment is quite a bit trickier, as that needs a new major 
> syntax class to describe the left side of the assignment. I suggest 
> omitting that from consideration at this stage.
>
> Donal.
>
> -------- Original message --------
> From: Colin Macleod via Tcl-Core <tcl...@li...>
> Date: 02/11/2025 08:13 (GMT+00:00)
> To: Pietro Cerutti <ga...@ga...>
> Cc: tcl...@li..., av...@lo...
> Subject: Re: [TCLCORE] Fwd: TIP 672 Implementation Complete - Ready 
> for Sponsorship
>
> Indeed, this toy implementation doesn't handle that:
>
>     % = sin (12)
>     can't read "sin": no such variable
>
> I'm not sure that's serious, but it could be fixed in a C implementation.
>

Re: [TCLCORE] Fwd: TIP 672 Implementation Complete - Ready for Sponsorship

[Colin M. <col...@ya...>]

Hi Florent,

I don't think anyone is suggesting removing the existing `expr` or 
making an incompatible change to it, just adding another form of expression.

Colin.

On 02/11/2025 14:11, Florent Merlet wrote:
>
> Hi Donal, Hi all :
>
> Is it not to much in matter of syntax change ?
>
> Will your ask everybody to change all their expr in all their script 
> to adopt the new Tcl Version ? The adoption of this new version will 
> be very long, if it ever happens. It may even finish by disgusting 
> people of Tcl itself.
>
> I think it's better to respect the actual Tcl C code, to say : Some 
> choices have been done, that can't be change anymore. This is the way 
> Tcl was build : let's see where it can go this way.
>
> Personnally, I'm not disturbed by the '$' sign, I'm very used to 
> it. When I see a '$' in Tcl, I think immediately : variable.
>
> That's why I'm not fond of the $((...)) syntax.
>
> In Tcl, the '$' sign is the mark of variable, whereas the '[ ... ]' is 
> the mark of command. It is an historical choice. It can be respected.
>
> To properly improve the expression handling, but without breaking 
> every expression, I think there is 5 things that can be done :
>
>   * 1° A shorthand syntax. Ex : [( ... )]
>   * 2° An instruction separator ";"
>   * 3° A native list handling via coma separator. Ex : [( $x, $y, $z
>     )] will return [list $x $y $z]
>   * 4° Support for {*}prefix, but adapted for expr, with coma separator,
>       o ex : [expr {{*}[list $x $y $z] }] means [expr {$x, $y, $z}]
>   * 5° An assignement operator :
>       o As the left value is a variable, and as a variable in Tcl is
>         mark by a '$', let's mark the left value... with a '$'
>           + This way, there won't be any ambiguity between command and
>             array, so a lot less of headaches !
>       o make it able to assign multiple value once.
>
> Then, we can write things like these :
>
> proc Coords {R theta} {
>     return [(
>          $x = $R*cos($theta);
>          $y = $R*sin($theta);
>          $x,$y )]
> }
>
> (86 chars) instead of (95 chars):
>
> proc Coord {R theta} {
>     set x [expr {$R*cos($theta)}]
>     set y [expr {$R*sin($theta)}]
>     return [list $x $y]
> }
>
> and
>
> proc Cross_Product {v1 v2} {
>     return [(
>          $x, $y, $z = {*}$v1;
>          $a, $b, $c = {*}$v2;
>          $y*$c-$z*$b, $z*$a-$x*$c, $x*$b-$y*$a )]
> }
>
> (132 chars) Instead of (175 chars):
>
> proc Cross_Product {v1 v2} {
>     lassign {x y z} $v1
>     lassign {a b c} $v2
>     set X [expr {$y*$c - $z*$b}]
>     set Y [expr {$z*$a - $x*$c}]
>     set Z [expr {$x*$b - $y*$a}]
>     return [list $X $Y $Z]
> }
>
> Of course, there is a lot of dollars : it is suboptimal on this point 
> of view. But I don't think that will not disturb too much a Tcl coder 
> that is use to associate it with variable.
>
> Moreover, every [expr { ... }] you wrote since you began Tcl will 
> still remain correct.
>
> Regards,
>
> Florent
>
> Le 02/11/2025 à 10:04, Donal Fellows a écrit :
>> Doing the job properly would definitely involve changing the 
>> expression parser, with my suggested fix being to turn all bare words 
>> not otherwise recognised as constants or in positions that look like 
>> function calls (it's a parser with some lookahead) into simple 
>> variable reads (NB: C resolves such ambiguities within itself 
>> differently, but that's one of the nastiest parts of the language). 
>> We would need to retain $ support for resolving ambiguity (e.g., 
>> array reads vs function calls; you can't safely inspect the 
>> interpreter to resolve it at the time of compiling the expression due 
>> to traces and unknown handlers) as well as compatibility, but that's 
>> doable as it is a change only in cases that are currently errors.
>>
>> Adding assignment is quite a bit trickier, as that needs a new major 
>> syntax class to describe the left side of the assignment. I suggest 
>> omitting that from consideration at this stage.
>>
>> Donal.
>>
>> -------- Original message --------
>> From: Colin Macleod via Tcl-Core <tcl...@li...>
>> Date: 02/11/2025 08:13 (GMT+00:00)
>> To: Pietro Cerutti <ga...@ga...>
>> Cc: tcl...@li..., av...@lo...
>> Subject: Re: [TCLCORE] Fwd: TIP 672 Implementation Complete - Ready 
>> for Sponsorship
>>
>> Indeed, this toy implementation doesn't handle that:
>>
>>     % = sin (12)
>>     can't read "sin": no such variable
>>
>> I'm not sure that's serious, but it could be fixed in a C implementation.
>>
>>
>>
>> _______________________________________________
>> Tcl-Core mailing list
>> Tcl...@li...
>> https://lists.sourceforge.net/lists/listinfo/tcl-core
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] Fwd: TIP 672 Implementation Complete - Ready for Sponsorship

[Florent M. <flo...@gm...>]

Hi Donal, Hi all :

Is it not to much in matter of syntax change ?

Will your ask everybody to change all their expr in all their script to 
adopt the new Tcl Version ? The adoption of this new version will be 
very long, if it ever happens. It may even finish by disgusting people 
of Tcl itself.

I think it's better to respect the actual Tcl C code, to say : Some 
choices have been done, that can't be change anymore. This is the way 
Tcl was build : let's see where it can go this way.

Personnally, I'm not disturbed by the '$' sign, I'm very used to 
it. When I see a '$' in Tcl, I think immediately : variable.

That's why I'm not fond of the $((...)) syntax.

In Tcl, the '$' sign is the mark of variable, whereas the '[ ... ]' is 
the mark of command. It is an historical choice. It can be respected.

To properly improve the expression handling, but without breaking every 
expression, I think there is 5 things that can be done :

  * 1° A shorthand syntax. Ex : [( ... )]
  * 2° An instruction separator ";"
  * 3° A native list handling via coma separator. Ex : [( $x, $y, $z )]
    will return [list $x $y $z]
  * 4° Support for {*}prefix, but adapted for expr, with coma separator,
      o ex : [expr {{*}[list $x $y $z] }] means [expr {$x, $y, $z}]
  * 5° An assignement operator :
      o As the left value is a variable, and as a variable in Tcl is
        mark by a '$', let's mark the left value... with a '$'
          + This way, there won't be any ambiguity between command and
            array, so a lot less of headaches !
      o make it able to assign multiple value once.

Then, we can write things like these :

proc Coords {R theta} {
     return [(
          $x = $R*cos($theta);
          $y = $R*sin($theta);
          $x,$y )]
}

(86 chars) instead of (95 chars):

proc Coord {R theta} {
     set x [expr {$R*cos($theta)}]
     set y [expr {$R*sin($theta)}]
     return [list $x $y]
}

and

proc Cross_Product {v1 v2} {
     return [(
          $x, $y, $z = {*}$v1;
          $a, $b, $c = {*}$v2;
          $y*$c-$z*$b, $z*$a-$x*$c, $x*$b-$y*$a )]
}

(132 chars) Instead of (175 chars):

proc Cross_Product {v1 v2} {
     lassign {x y z} $v1
     lassign {a b c} $v2
     set X [expr {$y*$c - $z*$b}]
     set Y [expr {$z*$a - $x*$c}]
     set Z [expr {$x*$b - $y*$a}]
     return [list $X $Y $Z]
}

Of course, there is a lot of dollars : it is suboptimal on this point of 
view. But I don't think that will not disturb too much a Tcl coder that 
is use to associate it with variable.

Moreover, every [expr { ... }] you wrote since you began Tcl will still 
remain correct.

Regards,

Florent

Le 02/11/2025 à 10:04, Donal Fellows a écrit :
> Doing the job properly would definitely involve changing the 
> expression parser, with my suggested fix being to turn all bare words 
> not otherwise recognised as constants or in positions that look like 
> function calls (it's a parser with some lookahead) into simple 
> variable reads (NB: C resolves such ambiguities within itself 
> differently, but that's one of the nastiest parts of the language). We 
> would need to retain $ support for resolving ambiguity (e.g., array 
> reads vs function calls; you can't safely inspect the interpreter to 
> resolve it at the time of compiling the expression due to traces and 
> unknown handlers) as well as compatibility, but that's doable as it is 
> a change only in cases that are currently errors.
>
> Adding assignment is quite a bit trickier, as that needs a new major 
> syntax class to describe the left side of the assignment. I suggest 
> omitting that from consideration at this stage.
>
> Donal.
>
> -------- Original message --------
> From: Colin Macleod via Tcl-Core <tcl...@li...>
> Date: 02/11/2025 08:13 (GMT+00:00)
> To: Pietro Cerutti <ga...@ga...>
> Cc: tcl...@li..., av...@lo...
> Subject: Re: [TCLCORE] Fwd: TIP 672 Implementation Complete - Ready 
> for Sponsorship
>
> Indeed, this toy implementation doesn't handle that:
>
>     % = sin (12)
>     can't read "sin": no such variable
>
> I'm not sure that's serious, but it could be fixed in a C implementation.
>
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] TIP 561 - Working console.tcl implementation with channel transforms

[EricT <tw...@gm...>]

Subject: Re: TIP 561 - Dynamic encoding fix and other updates

Ashok,

You're absolutely right - hardcoding UTF-8 was an oversight. Thank you for
catching that!

I've updated the transform to query the channel's encoding dynamically:

    # Get the channel's actual encoding instead of hardcoding UTF-8
    set enc [fconfigure $what -encoding]
    if {$enc ne "binary"} {
        set data [encoding convertfrom $enc $data]
    }

I'm not entirely sure how to test different encodings in practice, but the
change didn't break anything and the logic is clearly more correct.

I've also made several other improvements based on testing:

1. Removed the pre-8.6 puts wrapper code entirely (targeted for Tcl 9.1+)
2. Fixed console show/hide cycling so the console can be closed and
reopened multiple times
3. The console command now properly manages channel transforms on hide/show
4. Changed window close from "destroy" to "wm withdraw" for reopening
capability


The updated code is at: https://github.com/rocketship88/tcl-console-unix

When convenient, it would be great to get this merged into the TIP 561
branch. I appreciate it being on Tuesday's agenda, though unfortunately I
won't be able to attend (4 AM my time, and no mic/camera). I may try to
lurk if I'm awake.

Thank you,
Eric

On Sun, Nov 2, 2025 at 1:07 AM apnmbx-public--- via Tcl-Core <
tcl...@li...> wrote:

> Eric,
>
>
>
> I believe (but not completely sure) that the bytes are not always UTF-8
> encoded but rather encoded as per the channel’s configuration. So decoding
> should probably be done using whatever encoding has been configured for the
> channel.
>
>
>
> /Ashok
>
>
>
> *From:* EricT <tw...@gm...>
> *Sent:* Saturday, November 1, 2025 3:14 AM
> *To:* Tcl...@li...
> *Subject:* [TCLCORE] TIP 561 - Working console.tcl implementation with
> channel transforms
>
>
>
> Hello Tcl Core Team,
>
> I've successfully resolved the Unicode handling issues with the channel
> transform
> implementation for TIP 561 (Console command for Linux/Unix).
>
> The key fix was recognizing that channel transforms receive UTF-8 encoded
> bytes,
> which need to be decoded back to Unicode strings before passing to the Tk
> console
> widget:
>
>     set data [encoding convertfrom utf-8 $data]
>
> This eliminates the need for the pre-8.6 puts wrapper method, providing a
> clean,
> API-based solution using TIP#230 channel transforms.
>
> The working implementation is available at:
>
> https://github.com/rocketship88/tcl-console-unix
>
> Since I don't have permissions to update the TIP or its branch, could
> someone
> kindly review the code and update console.tcl in the TIP 561 repository if
> it
> looks acceptable?
>
> The implementation has been tested on Pop!_OS Linux with proper Unicode
> display,
> console cleanup, and output restoration to the terminal.
>
> Thank you,
> Eric
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

Re: [TCLCORE] Fwd: TIP 672 Implementation Complete - Ready for Sponsorship

[Donal F. <don...@ma...>]

Doing the job properly would definitely involve changing the expression parser, with my suggested fix being to turn all bare words not otherwise recognised as constants or in positions that look like function calls (it's a parser with some lookahead) into simple variable reads (NB: C resolves such ambiguities within itself differently, but that's one of the nastiest parts of the language). We would need to retain $ support for resolving ambiguity (e.g., array reads vs function calls; you can't safely inspect the interpreter to resolve it at the time of compiling the expression due to traces and unknown handlers) as well as compatibility, but that's doable as it is a change only in cases that are currently errors.

Adding assignment is quite a bit trickier, as that needs a new major syntax class to describe the left side of the assignment. I suggest omitting that from consideration at this stage.

Donal.

-------- Original message --------
From: Colin Macleod via Tcl-Core <tcl...@li...>
Date: 02/11/2025 08:13 (GMT+00:00)
To: Pietro Cerutti <ga...@ga...>
Cc: tcl...@li..., av...@lo...
Subject: Re: [TCLCORE] Fwd: TIP 672 Implementation Complete - Ready for Sponsorship


Indeed, this toy implementation doesn't handle that:

% = sin (12)
can't read "sin": no such variable

I'm not sure that's serious, but it could be fixed in a C implementation.

Re: [TCLCORE] Fwd: TIP 672 Implementation Complete - Ready for Sponsorship

[Donal F. <don...@ma...>]

Doing the job properly would definitely involve changing the expression parser, with my suggested fix being to turn all bare words not otherwise recognised as constants or in positions that look like function calls (it's a parser with some lookahead) into simple variable reads (NB: C resolves such ambiguities within itself differently, but that's one of the nastiest parts of the language). We would need to retain $ support for resolving ambiguity (e.g., array reads vs function calls; you can't safely inspect the interpreter to resolve it at the time of compiling the expression due to traces and unknown handlers) as well as compatibility, but that's doable as it is a change only in cases that are currently errors.

Adding assignment is quite a bit trickier, as that needs a new major syntax class to describe the left side of the assignment. I suggest omitting that from consideration at this stage.

Donal.

-------- Original message --------
From: Colin Macleod via Tcl-Core <tcl...@li...>
Date: 02/11/2025 08:13 (GMT+00:00)
To: Pietro Cerutti <ga...@ga...>
Cc: tcl...@li..., av...@lo...
Subject: Re: [TCLCORE] Fwd: TIP 672 Implementation Complete - Ready for Sponsorship


Indeed, this toy implementation doesn't handle that:

% = sin (12)
can't read "sin": no such variable

I'm not sure that's serious, but it could be fixed in a C implementation.

Re: [TCLCORE] Fwd: TIP 672 Implementation Complete - Ready for Sponsorship

[Donal F. <don...@ma...>]

Doing the job properly would definitely involve changing the expression parser, with my suggested fix being to turn all bare words not otherwise recognised as constants or in positions that look like function calls (it's a parser with some lookahead) into simple variable reads (NB: C resolves such ambiguities within itself differently, but that's one of the nastiest parts of the language). We would need to retain $ support for resolving ambiguity (e.g., array reads vs function calls; you can't safely inspect the interpreter to resolve it at the time of compiling the expression due to traces and unknown handlers) as well as compatibility, but that's doable as it is a change only in cases that are currently errors.

Adding assignment is quite a bit trickier, as that needs a new major syntax class to describe the left side of the assignment. I suggest omitting that from consideration at this stage.

Donal.

-------- Original message --------
From: Colin Macleod via Tcl-Core <tcl...@li...>
Date: 02/11/2025 08:13 (GMT+00:00)
To: Pietro Cerutti <ga...@ga...>
Cc: tcl...@li..., av...@lo...
Subject: Re: [TCLCORE] Fwd: TIP 672 Implementation Complete - Ready for Sponsorship


Indeed, this toy implementation doesn't handle that:

% = sin (12)
can't read "sin": no such variable

I'm not sure that's serious, but it could be fixed in a C implementation.

Re: [TCLCORE] Fwd: TIP 672 Implementation Complete - Ready for Sponsorship

[Donal F. <don...@ma...>]

Doing the job properly would definitely involve changing the expression parser, with my suggested fix being to turn all bare words not otherwise recognised as constants or in positions that look like function calls (it's a parser with some lookahead) into simple variable reads (NB: C resolves such ambiguities within itself differently, but that's one of the nastiest parts of the language). We would need to retain $ support for resolving ambiguity (e.g., array reads vs function calls; you can't safely inspect the interpreter to resolve it at the time of compiling the expression due to traces and unknown handlers) as well as compatibility, but that's doable as it is a change only in cases that are currently errors.

Adding assignment is quite a bit trickier, as that needs a new major syntax class to describe the left side of the assignment. I suggest omitting that from consideration at this stage.

Donal.

-------- Original message --------
From: Colin Macleod via Tcl-Core <tcl...@li...>
Date: 02/11/2025 08:13 (GMT+00:00)
To: Pietro Cerutti <ga...@ga...>
Cc: tcl...@li..., av...@lo...
Subject: Re: [TCLCORE] Fwd: TIP 672 Implementation Complete - Ready for Sponsorship


Indeed, this toy implementation doesn't handle that:

% = sin (12)
can't read "sin": no such variable

I'm not sure that's serious, but it could be fixed in a C implementation.

Re: [TCLCORE] Fwd: TIP 672 Implementation Complete - Ready for Sponsorship

[Donal F. <don...@ma...>]

Doing the job properly would definitely involve changing the expression parser, with my suggested fix being to turn all bare words not otherwise recognised as constants or in positions that look like function calls (it's a parser with some lookahead) into simple variable reads (NB: C resolves such ambiguities within itself differently, but that's one of the nastiest parts of the language). We would need to retain $ support for resolving ambiguity (e.g., array reads vs function calls; you can't safely inspect the interpreter to resolve it at the time of compiling the expression due to traces and unknown handlers) as well as compatibility, but that's doable as it is a change only in cases that are currently errors.

Adding assignment is quite a bit trickier, as that needs a new major syntax class to describe the left side of the assignment. I suggest omitting that from consideration at this stage.

Donal.

-------- Original message --------
From: Colin Macleod via Tcl-Core <tcl...@li...>
Date: 02/11/2025 08:13 (GMT+00:00)
To: Pietro Cerutti <ga...@ga...>
Cc: tcl...@li..., av...@lo...
Subject: Re: [TCLCORE] Fwd: TIP 672 Implementation Complete - Ready for Sponsorship


Indeed, this toy implementation doesn't handle that:

% = sin (12)
can't read "sin": no such variable

I'm not sure that's serious, but it could be fixed in a C implementation.

Re: [TCLCORE] Fwd: TIP 672 Implementation Complete - Ready for Sponsorship

[Colin M. <col...@ya...>]

Indeed, this toy implementation doesn't handle that:

    % = sin (12)
    can't read "sin": no such variable

I'm not sure that's serious, but it could be fixed in a C implementation.

Colin.

On 02/11/2025 08:04, Pietro Cerutti wrote:
> How does it handle a space between a mathfunc and its parenthesized 
> argument list?
>
> % expr {sin (12)}
> -0.5365729180004349
>
> -- 
> Pietro Cerutti
> I've pledged to give 10% of income to effective charitiesand invite 
> you to join me.
> https://givingwhatwecan.org
>
> Sent from a small device - please excuse brevity and typos.
>
>
>> On 1 Nov 2025, at 17:50, Colin Macleod via Tcl-Core 
>> <tcl...@li...> wrote:
>>
>> 
>> On 30/10/2025 01:18, Andreas Leitgeb wrote:
>>>    - [= ...] with a modified expr-language using barewords as variable
>>>      names would probably solve many (if not most) of the cases, where
>>>      [expr {...}] really "hurts" for its verbosity.
>>
>> Here is a pure Tcl implementation of that:
>>
>>     proc = args {
>>         set ex [join $args]
>>         set exp [regsub -all
>>     {(::)?[[:alpha:]]([[:alnum:]_]|::)*([^[:alnum:]_(]|$)} $ex {$&}]
>>         uplevel expr $exp
>>     }
>>
>> This just finds all the possible variable names in the expression, 
>> prefixes them with $ and then runs expr on the result.  The regex is 
>> a little complicated because:
>>
>>   * The variable name could include :: at the beginning or in the
>>     middle for namespacing.
>>   * We disallow single colon : within the name because that creates
>>     ambiguity with the ternary operator ?: .
>>   * We also disallow array references because we can't distinguish
>>     them from mathfunc calls.
>>
>> The fact that this can be implemented in pure Tcl shows that it 
>> doesn't require any change to the dodekalogue rules, and so there is 
>> no consequence for subst either.
>>
>> Of course a real implementation should be done in C.  It could then 
>> also be possible to implement the extension Kevin Kenny suggested of 
>> adding `=` as an assignment operator as in C within an expression, 
>> and perhaps even chaining multiple assignments with `,` .
>>
>> I saw the `expr` question is on the agenda for the call on Monday.  I 
>> don't usually join these calls but I would join it for this issue 
>> except that I have an urgent dentist's appointment at that time.  
>> Perhaps I should create a new TIP for this proposal?
>>
>> Colin.
>>
>> _______________________________________________
>> Tcl-Core mailing list
>> Tcl...@li...
>> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] TIP 561 - Working console.tcl implementation with channel transforms

[<apn...@ya...>]

Eric,

 

I believe (but not completely sure) that the bytes are not always UTF-8 encoded but rather encoded as per the channel’s configuration. So decoding should probably be done using whatever encoding has been configured for the channel.

 

/Ashok 

 

From: EricT <tw...@gm...> 
Sent: Saturday, November 1, 2025 3:14 AM
To: Tcl...@li...
Subject: [TCLCORE] TIP 561 - Working console.tcl implementation with channel transforms

 

Hello Tcl Core Team,

I've successfully resolved the Unicode handling issues with the channel transform 
implementation for TIP 561 (Console command for Linux/Unix).

The key fix was recognizing that channel transforms receive UTF-8 encoded bytes, 
which need to be decoded back to Unicode strings before passing to the Tk console 
widget:

    set data [encoding convertfrom utf-8 $data]

This eliminates the need for the pre-8.6 puts wrapper method, providing a clean, 
API-based solution using TIP#230 channel transforms.

The working implementation is available at:

https://github.com/rocketship88/tcl-console-unix

Since I don't have permissions to update the TIP or its branch, could someone 
kindly review the code and update console.tcl in the TIP 561 repository if it 
looks acceptable?

The implementation has been tested on Pop!_OS Linux with proper Unicode display, 
console cleanup, and output restoration to the terminal.

Thank you,
Eric

Re: [TCLCORE] Fwd: TIP 672 Implementation Complete - Ready for Sponsorship

[Pietro C. <ga...@ga...>]

How does it handle a space between a mathfunc and its parenthesized argument list?

% expr {sin (12)}
-0.5365729180004349

-- 
Pietro Cerutti
I've pledged to give 10% of income to effective charities and invite you to join me.
https://givingwhatwecan.org

Sent from a small device - please excuse brevity and typos.


> On 1 Nov 2025, at 17:50, Colin Macleod via Tcl-Core <tcl...@li...> wrote:
> 
> 
> On 30/10/2025 01:18, Andreas Leitgeb wrote:
>> 
>>    - [= ...] with a modified expr-language using barewords as variable
>>     names would probably solve many (if not most) of the cases, where
>>     [expr {...}] really "hurts" for its verbosity.
> Here is a pure Tcl implementation of that:
> 
> proc = args {
>     set ex [join $args]
>     set exp [regsub -all {(::)?[[:alpha:]]([[:alnum:]_]|::)*([^[:alnum:]_(]|$)} $ex {$&}]
>     uplevel expr $exp
> }
> 
> This just finds all the possible variable names in the expression, prefixes them with $ and then runs expr on the result.  The regex is a little complicated because:
> 
> The variable name could include :: at the beginning or in the middle for namespacing.
> We disallow single colon : within the name because that creates ambiguity with the ternary operator ?: .
> We also disallow array references because we can't distinguish them from mathfunc calls.
> The fact that this can be implemented in pure Tcl shows that it doesn't require any change to the dodekalogue rules, and so there is no consequence for subst either.
> 
> Of course a real implementation should be done in C.  It could then also be possible to implement the extension Kevin Kenny suggested of adding `=` as an assignment operator as in C within an expression, and perhaps even chaining multiple assignments with `,` .
> 
> I saw the `expr` question is on the agenda for the call on Monday.  I don't usually join these calls but I would join it for this issue except that I have an urgent dentist's appointment at that time.  Perhaps I should create a new TIP for this proposal?
> 
> Colin.
> 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

[TCLCORE] TIP 732 ready for comments

[<apn...@ya...>]

 <https://core.tcl-lang.org/tips/doc/trunk/tip/732.md> TIP 732: Changes to
the Tcl script library search path is ready for comments.

 

TL;DR formalizes the mechanisms by which that Tcl runs/locates its support
scripts (init.tcl) and encodings. Currently this is partly undocumented and
also has some inconsistencies between documentation and behaviour. Further,
the TIP removes some search locations. See TIP for motivation and details.

 

The accompanying implementation also moves some of the Tcl initialization
scripts into C for a significant (25%) reduction in interp creation time.

 

I'm particularly interested in feedback from Unix and macOS folks that build
distributions if this impacts them in any way.

 

/Ashok

[TCLCORE] CFV: TIP 733, Add accessibility/screen reader support to Tk

[Kevin W. <kw...@co...>]

Hi all,

I've had no additional feedback on TIP 733 in the past week, and I 
believe the tka11y branch is ready for merging, so I'd like to call for 
a TCT vote.

Let's have votes in by [clock format 1762559940 -gmt 1].

My vote: TIP 733: YES

--Kevin

Re: [TCLCORE] Fwd: TIP 672 Implementation Complete - Ready for Sponsorship

[Colin M. <col...@ya...>]

One point I forgot - a serious C implementation of this should probably 
disallow any further $ or [] substitution after substituting the bare 
variable names.  This could also have a secondary use-case as a safe way 
to run user-specified calculations.

On 01/11/2025 16:49, Colin Macleod via Tcl-Core wrote:
> On 30/10/2025 01:18, Andreas Leitgeb wrote:
>>    - [= ...] with a modified expr-language using barewords as variable
>>      names would probably solve many (if not most) of the cases, where
>>      [expr {...}] really "hurts" for its verbosity.
>
> Here is a pure Tcl implementation of that:
>
>     proc = args {
>         set ex [join $args]
>         set exp [regsub -all
>     {(::)?[[:alpha:]]([[:alnum:]_]|::)*([^[:alnum:]_(]|$)} $ex {$&}]
>         uplevel expr $exp
>     }
>
> This just finds all the possible variable names in the expression, 
> prefixes them with $ and then runs expr on the result.  The regex is a 
> little complicated because:
>
>   * The variable name could include :: at the beginning or in the
>     middle for namespacing.
>   * We disallow single colon : within the name because that creates
>     ambiguity with the ternary operator ?: .
>   * We also disallow array references because we can't distinguish
>     them from mathfunc calls.
>
> The fact that this can be implemented in pure Tcl shows that it 
> doesn't require any change to the dodekalogue rules, and so there is 
> no consequence for subst either.
>
> Of course a real implementation should be done in C.  It could then 
> also be possible to implement the extension Kevin Kenny suggested of 
> adding `=` as an assignment operator as in C within an expression, and 
> perhaps even chaining multiple assignments with `,` .
>
> I saw the `expr` question is on the agenda for the call on Monday.  I 
> don't usually join these calls but I would join it for this issue 
> except that I have an urgent dentist's appointment at that time.  
> Perhaps I should create a new TIP for this proposal?
>
> Colin.
>
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] Fwd: TIP 672 Implementation Complete - Ready for Sponsorship

[Colin M. <col...@ya...>]

On 30/10/2025 01:18, Andreas Leitgeb wrote:
>    - [= ...] with a modified expr-language using barewords as variable
>      names would probably solve many (if not most) of the cases, where
>      [expr {...}] really "hurts" for its verbosity.

Here is a pure Tcl implementation of that:

    proc = args {
         set ex [join $args]
         set exp [regsub -all
    {(::)?[[:alpha:]]([[:alnum:]_]|::)*([^[:alnum:]_(]|$)} $ex {$&}]
         uplevel expr $exp
    }

This just finds all the possible variable names in the expression, 
prefixes them with $ and then runs expr on the result.  The regex is a 
little complicated because:

  * The variable name could include :: at the beginning or in the middle
    for namespacing.
  * We disallow single colon : within the name because that creates
    ambiguity with the ternary operator ?: .
  * We also disallow array references because we can't distinguish them
    from mathfunc calls.

The fact that this can be implemented in pure Tcl shows that it doesn't 
require any change to the dodekalogue rules, and so there is no 
consequence for subst either.

Of course a real implementation should be done in C.  It could then also 
be possible to implement the extension Kevin Kenny suggested of adding 
`=` as an assignment operator as in C within an expression, and perhaps 
even chaining multiple assignments with `,` .

I saw the `expr` question is on the agenda for the call on Monday.  I 
don't usually join these calls but I would join it for this issue except 
that I have an urgent dentist's appointment at that time.  Perhaps I 
should create a new TIP for this proposal?

Colin.