tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] Manpage updates for review

[Andreas K. <aku...@su...>]

Note https://en.wikipedia.org/wiki/UTF-8#Modified_UTF-8
> Java <https://en.wikipedia.org/wiki/Java_(programming_language)>
internally uses UTF-16 for the *char* data type and, consequentially,
> the *Character*, *String*, and the *StringBuffer* classes,[61]
<https://en.wikipedia.org/wiki/UTF-8#cite_note-61> but
> for I/O uses *Modified UTF-8* (MUTF-8), in which the null character
<https://en.wikipedia.org/wiki/Null_character> U+0000
> uses the two-byte overlong encoding 0xC0, 0x80, instead of just 0x00.[18]
<https://en.wikipedia.org/wiki/UTF-8#cite_note-:2-18>
And:
> Tcl <https://en.wikipedia.org/wiki/Tcl> also uses the same modified UTF-8[
68] <https://en.wikipedia.org/wiki/UTF-8#cite_note-68> as Java for internal
> representation of Unicode data, but uses strict CESU-8 for external data.

(https://en.wikipedia.org/wiki/CESU-8)

On Tue, Nov 11, 2025 at 2:00 PM Pietro Cerutti via Tcl-Core <
tcl...@li...> wrote:

> On Nov 11 2025, 05:33 +0000, apnmbx-public--- via Tcl-Core <
> tcl...@li...> wrote:
> [-- Type: text/html; charset=utf-8, Encoding: quoted-printable, Size: 4.9K
> --]
> >The branch [1]apn-doc-update contains manpage updates addressing two
> areas –
> >
> >
> >
> >  ● added a section in Tcl.n that defines Tcl string value as a sequence
> of
> >    Unicode code points.
> >  ● updates to various command and C API pages that wrongly identify Tcl’s
> >    internal format as UTF-8. For this purpose the encoding name TUTF-8
> has
> >    been introduced to reference Tcl’s internal modified UTF-8 format.
> >
> >
> >
> >Reviews appreciated and improvements welcome. Both have been a pet peeve
> with
> >me for a long time (and probably no one else!) in that the first is
> important
> >missing information and the second is misinformation.
>
> Would it make sense to descibe TUTF-8 in its own dedicated man page and
> referent to it, instead of duplicating the description across different
> man pages?
>
>
> --
> Pietro Cerutti
> I have pledged to give 10% of income to effective charities
> and invite you to join me - https://givingwhatwecan.org
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>


-- 
Andreas Kupries - SUSE Software Solutions Germany GmbH, Frankenstr. 146,
90461 Nürnberg, Germany, www.suse.com <http://www.suse.com/>,
Geschäftsführer: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB
36809, AG Nürnberg)

Re: [TCLCORE] Manpage updates for review

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

On Nov 11 2025, 05:33 +0000, apnmbx-public--- via Tcl-Core <tcl...@li...> wrote:
[-- Type: text/html; charset=utf-8, Encoding: quoted-printable, Size: 4.9K --]
>The branch [1]apn-doc-update contains manpage updates addressing two areas –
>
> 
>
>  ● added a section in Tcl.n that defines Tcl string value as a sequence of
>    Unicode code points.
>  ● updates to various command and C API pages that wrongly identify Tcl’s
>    internal format as UTF-8. For this purpose the encoding name TUTF-8 has
>    been introduced to reference Tcl’s internal modified UTF-8 format.
>
> 
>
>Reviews appreciated and improvements welcome. Both have been a pet peeve with
>me for a long time (and probably no one else!) in that the first is important
>missing information and the second is misinformation.

Would it make sense to descibe TUTF-8 in its own dedicated man page and 
referent to it, instead of duplicating the description across different 
man pages?


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

Re: [TCLCORE] Manpage updates for review

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

Am 11.11.2025 um 06:33 schrieb apnmbx-public--- via Tcl-Core:
> The branch apn-doc-update <https://core.tcl-lang.org/tcl/timeline?r=apn- 
> doc-update> contains manpage updates addressing two areas –
> 
>   * added a section in Tcl.n that defines Tcl string value as a sequence
>     of Unicode code points.
>   * updates to various command and C API pages that wrongly identify
>     Tcl’s internal format as UTF-8. For this purpose the encoding name
>     TUTF-8 has been introduced to reference Tcl’s internal modified
>     UTF-8 format.
> 
> Reviews appreciated and improvements welcome. Both have been a pet peeve 
> with me for a long time (and probably no one else!) in that the first is 
> important missing information and the second is misinformation.
> 
> I plan to merge in a couple of weeks. Silence will be construed as 
> approval 😊
> 
> /Ashok
+1, great proposal!

Side note: At one point, the documentation speaks about "normalized 
(T)UTF-8". I only saw it in the diff. Normalized utf-8 is a big word...

And I always learn new English terms like "pet peeve" from you, thanks 
for that.

Take care,
Harald

Re: [TCLCORE] Tcl/Tk 9.0.3 Release Candidate

[Torsten B. <be...@ty...>]

Hi,

I keep getting this error on macOS (Ventrua 13.7.8)

Building package 'sqlite3.51.0' for Tcl 8
echo "#define SQLITE3_VERSION_UUID \\" >sqlite3Uuid.h
If you have documentation to create, place the commands to
cat /Users/Torsten/Tcl/distrib/tcl9.0.3-arm64/pkgs/sqlite3.51.0/manifest.uuid >>sqlite3Uuid.h
build the docs in the 'doc:' target.  For example:
echo "" >>sqlite3Uuid.h
        xml2nroff sample.xml > sample.n
gcc -DPACKAGE_NAME=\"sqlite\" -DPACKAGE_TARNAME=\"sqlite\" -DPACKAGE_VERSION=\"3.51.0\" -DPACKAGE_STRING=\"sqlite\ 3.51.0\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DBUILD_sqlite=/\*\*/ -DHAVE_STDIO_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_STRINGS_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_UNISTD_H=1 -DSTDC_HEADERS=1 -DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 -D_THREAD_SAFE=1 -DTCL_THREADS=1 -DSQLITE_THREADSAFE=1 -DUSE_TCL_STUBS=1 -DUSE_TCLOO_STUBS=1 -DMODULE_SCOPE=extern\ __attribute__\(\(__visibility__\(\"hidden\"\)\)\) -DHAVE_HIDDEN=1 -DHAVE_CAST_TO_UNION=1 -DHAVE_STDBOOL_H=1 -DTCL_WIDE_INT_IS_LONG=1 -DUSE_TCL_STUBS=1 -DHAVE_FDATASYNC=1 -DHAVE_USLEEP=1 -DHAVE_LOCALTIME_R=1 -DHAVE_GMTIME_R=1 -DHAVE_UTIME=1 -DHAVE_FLOCK=1 -DHAVE_READLINK=1 -DHAVE_LSTAT=1 -DHAVE_PREAD=1 -DHAVE_PWRITE=1 -DHAVE_DECL_STRERROR_R=1 -DHAVE_STRERROR_R=1 -DTCL_MAJOR_VERSION=8 -DTK_MAJOR_VERSION=8 -DSQLITE_ENABLE_DBPAGE_VTAB=1 -DSQLITE_ENABLE_DBSTAT_VTAB=1 -DSQLITE_ENABLE_FTS3_PARENTHESIS=1 -DSQLITE_ENABLE_FTS4=1 -DSQLITE_ENABLE_FTS5=1 -DSQLITE_ENABLE_COLUMN_METADATA=1 -DSQLITE_ENABLE_JSON1=1 -DSQLITE_3_SUFFIX_ONLY=1 -DSQLITE_ENABLE_RTREE=1 -DSQLITE_ENABLE_GEOPOLY=1 -DSQLITE_ENABLE_STAT4=1 -DSQLITE_ENABLE_UPDATE_DELETE_LIMIT=1 -DSQLITE_ENABLE_MATH_FUNCTIONS=1 -DSQLITE_ENABLE_DESERIALIZE=1 -DSQLITE_ENABLE_BYTECODE_VTAB=1 -DSQLITE_ENABLE_UNKNOWN_SQL_FUNCTION=1 -DSQLITE_ENABLE_STMTVTAB=1 -DSQLITE_ENABLE_BYTECODE_VTAB=1 -DSQLITE_ENABLE_OFFSET_SQL_FUNC=1 -DSQLITE_ENABLE_PERCENTILE=1 -DSQLITE_STRICT_SUBTYPE=1 -DSQLITE_LIKE_DOESNT_MATCH_BLOBS=1 -DSQLITE_UNTESTABLE=1 -DSQLITE_OMIT_DEPRECATED=1 -DSQLITE_OMIT_LOOKASIDE=1 -DSQLITE_SECURE_DELETE=1 -DSQLITE_SOUNDEX=1 -DSQLITE_USE_ALLOCA=1 -DSQLITE_WIN32_NO_ANSI=1 -DSQLITE_WIN32_GETVERSIONEX=0 -DSQLITE_API=MODULE_SCOPE -DSQLITE_EXTERN= -I"/Users/Torsten/Tcl/distrib/tcl9.0.3-arm64/pkgs/sqlite3.51.0/generic" -I"/Users/Torsten/Tcl/distrib/tcl9.0.3-arm64/generic" -I. -I/Users/Torsten/Tcl/distrib/tcl9.0.3-arm64/pkgs/sqlite3.51.0/..    -g -Wall -fno-common -pipe  -g -Wall -fno-common  -mmacosx-version-min=11  -c `echo /Users/Torsten/Tcl/distrib/tcl9.0.3-arm64/pkgs/sqlite3.51.0/generic/tclsqlite3.c` -o tclsqlite3.o
        xml2html sample.xml > sample.html
rm -f libsqlite3.51.0.dylib
gcc -dynamiclib -pipe  -g -Wall -fno-common  -mmacosx-version-min=11   -current_version 3.51.0 -compatibility_version 3.51.0 -headerpad_max_install_names -Wl,-search_paths_first   -o libsqlite3.51.0.dylib tclsqlite3.o -lpthread  -L/Users/Torsten/Tcl/distrib/build/tcl/Development -ltclstub 
ld: Undefined symbols:
  _Tcl_GetBoolFromObj, referenced from:
      _DbMain in tclsqlite3.o
      _DbMain in tclsqlite3.o
      _DbMain in tclsqlite3.o
      _DbMain in tclsqlite3.o
      _DbMain in tclsqlite3.o
      _DbMain in tclsqlite3.o
      _DbMain in tclsqlite3.o
      ...
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[4]: *** [libsqlite3.51.0.dylib] Error 1
make[3]: *** [packages] Error 2
make[2]: *** [build-tcl] Error 2
make[1]: *** [tcl] Error 2
make: *** [develop] Error 2


I had trouble compiling SQLite 3.51.0 from its sources too, until a user fixed a problem:

https://sqlite.org/forum/forumpost/389916bad5

Could this be the case here too? Also, I wonder why it is saying "Building package 'sqlite3.51.0' for Tcl 8" ...


Regards, Torsten


> Am 11.11.2025 um 18:55 schrieb Jan Nijtmans <jan...@gm...>:
> 
> Now available at
> 
> https://sourceforge.net/projects/tcl/files/Tcl/9.0.3/
> 
> are RC1 candidate source code distribution pre-releases of Tcl/Tk 9.0.3
> 
> This is the second candidate release leading to the release of Tcl/Tk
> 9.0.3. Testing of builds
> and operations on multiple platforms is invited.  Any critical problem
> that should block
> the release should be reported immediately.
> 
> Only the full *-src.tar.gz files are there, the zip-files and the stripped-down
> versions will follow.
> 
> Preliminary release notes are available as well. Please report any
> suggestions/improvements you may find.
> 
> I intend to rename those files to the final release in 2 days,
> thursday Nov 13.
> 
> Thank you for your contributions and assistance.
>           Jan Nijtmans
> 
> 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] Merge intention for Tk project skip_entire_test_files

[Erik L. <el...@xs...>]

On 11/10/25 20:48, Erik Leunissen via Tcl-Core wrote:

> ... I will carry out the
> intended merge on next Wednesday (or the first opportunity for me thereafter),
> but no earlier than that trunk is in good order, i.e. the Tk test suite passes
> for trunk on Github CI for all platforms.

and only after Tk9.0.3 has been released.

Regards,
Erik.
--

Re: [TCLCORE] [Ext] Re: [=] for concise expressions (was Re: TIP 672 Implementation Complete - Ready for Sponsorship)

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

HI All,

Sorry, I would not plan to do assignments or multiple calculations in 
the first version of [=]. I would leave these as possible enhancements 
for later. I do think there is less need for these features anyway if a 
single expression can be written concisely.

I have put an updated version of my prototype at 
https://cmacleod.me.uk/tcl/expr_ng2. This incorporates the cache Eric 
introduced, but then diverges from his version somewhat.

I have kept the command name as `=`, I think that's more clear than `:` 
to introduce a calculation.

I have introduced an `extract_numbers` step before tokenisation. The 
point of this is to enable pre-substituted array elements e.g. $a(b) or 
command substitutions, e.g. [llength $list], which produce numeric 
values, to be used efficiently.  If these are written as separate 
arguments (separated by spaces from the rest of the expression) then we 
check whether that argument already has a numeric internal 
representation.  If so, we assign it to a temporary variable and replace 
it in the expression with a reference to that temporary variable.  This 
avoids shimmering the value to/from string form.  But more importantly 
it allows us to cache the generated bytecode, because the name of the 
temporary variable will stay the same although its value may change.

Writing the `extract_numbers` step in Tcl is extremely kludgy, it does a 
regexp match on the output of tcl::unsupported::representation, ignoring 
the warning at https://wiki.tcl-lang.org/page/representation that this 
should not be used in program logic.  It's also slow, though still 
faster than invalidating the cache.  But I still see this prototype as a 
precursor to implementation in C, so I'm not too worried.

Some timings:

Without `extract_numbers`, expression without pre-substitution:
(bin) 149 % timerate {set z [= z *0.9999]}
2.246294 µs/# 445176 # 445177 #/sec 999.996 net-ms

Without `extract_numbers`, expression with pre-substitution:
(bin) 151 % timerate {set z [= $z *0.9999]}
22.4901 µs/# 110649 # 44464.1 #/sec 2488.502 net-ms

With `extract_numbers`, expression without pre-substitution:
(bin) 153 % timerate {set z [= z *0.9999]}
13.6414 µs/# 73306 # 73306.1 #/sec 999.999 net-ms

With `extract_numbers`, expression with pre-substitution:
(bin) 154 % timerate {set z [= $z *0.9999]}
15.7187 µs/# 63618 # 63618.6 #/sec 999.990 net-ms

So even with the klunky Tcl implementation the `extract_numbers` step 
still gives a speed-up when there is a pre-substituted numeric value.  A 
C implementation of this logic should be much more efficient.  Of course 
this speed-up is lost if a pre-substitution is not written as a separate 
argument, e.g. [= [llength $l] +2] will get the speed-up but [= [llength 
$l]+2] will not, so the documentation should warn about this.

Colin.

On 10/11/2025 07:20, Zaumseil René via Tcl-Core wrote:
>
> Hi Eric
>
> Thank you for your effort to bring this topic forward.
>
> Imho Colin's syntax is even better as the let version.
>
> I hope one of your proposals will make it into the core.
>
> Regards
>
> rene
>
> *Von:*EricT <tw...@gm...>
> *Gesendet:* Freitag, 7. November 2025 21:35
> *An:* Zaumseil René <RZa...@kk...>
> *Cc:* tc...@ro...; tcl...@li...
> *Betreff:* Re: [TCLCORE] [Ext] Re: [=] for concise expressions (was 
> Re: TIP 672 Implementation Complete - Ready for Sponsorship)
>
> Rene,
>
> That's the beauty of making bytecode compilation official - we DON'T 
> have to agree on syntax! With a supported tcl::bytecode API, each of 
> us can create our own Design-Specific Language for our own needs. No 
> more "one size fits all" debates that go nowhere.
>
> That said, I think you might find Colin's approach already fits your 
> needs quite well. Here's how your examples would look:
>
> Multiple assignments:
>
> # Your let syntax
> let {x 1+2 y 3*4 z $x+$y}
>
> # Colin's syntax (bare variables, no $)
> : {x = 1+2
>    y = 3*4
>    z = x+y}
>
>
> For my own taste, I've here aliased = to : since = as the command 
> seems to clash visually with = for assignment, especially in cases 
> like a = b = c = d. The semicolon requires braces since it's special 
> to Tcl, but by mapping newlines to semicolons internally, multiple 
> statements work naturally in braced blocks as shown above.
>
> Returning multiple values:
>
> # With a simple helper function
> proc tcl::mathfunc::gather {args} { list {*}$args }
>
> # Your canvas example
> .c create text {*}[= gather(x+1, y+1)] -text a
>
> # Or inline
> = {tx = x+1 ; ty = y+1 ; gather(tx, ty)}
>
>
> Your calculations example:
>
> set i 0.5
> = {x = sin(i)
>    y = cos(i) + x
>    z = x + y}
>
>
> The key differences: bare variables (no $), explicit = for assignment, 
> semicolon (or newline) to separate multiple expressions, and gather() 
> for multiple returns. But it's all extensible - add your own functions 
> to tcl::mathfunc:: and they're automatically available.
>
> If you prefer different syntax, you can build your let command using 
> the same bytecode infrastructure. That's the whole point - multiple 
> DSLs coexisting, each optimized by bytecode caching.
>
>
> Eric
>

[TCLCORE] Tcl/Tk 9.0.3 Release Candidate

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

Now available at

https://sourceforge.net/projects/tcl/files/Tcl/9.0.3/

are RC1 candidate source code distribution pre-releases of Tcl/Tk 9.0.3

This is the second candidate release leading to the release of Tcl/Tk
9.0.3. Testing of builds
and operations on multiple platforms is invited.  Any critical problem
that should block
the release should be reported immediately.

Only the full *-src.tar.gz files are there, the zip-files and the stripped-down
versions will follow.

Preliminary release notes are available as well. Please report any
suggestions/improvements you may find.

I intend to rename those files to the final release in 2 days,
thursday Nov 13.

Thank you for your contributions and assistance.
           Jan Nijtmans

[TCLCORE] Manpage updates for review

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

The branch apn-doc-update <https://core.tcl-lang.org/tcl/timeline?r=apn-doc-update>  contains manpage updates addressing two areas –

 

*	added a section in Tcl.n that defines Tcl string value as a sequence of Unicode code points.
*	updates to various command and C API pages that wrongly identify Tcl’s internal format as UTF-8. For this purpose the encoding name TUTF-8 has been introduced to reference Tcl’s internal modified UTF-8 format.

 

Reviews appreciated and improvements welcome. Both have been a pet peeve with me for a long time (and probably no one else!) in that the first is important missing information and the second is misinformation.

 

I plan to merge in a couple of weeks. Silence will be construed as approval 😊 

 

/Ashok

[TCLCORE] Merge intention for Tk project skip_entire_test_files

[Erik L. <el...@xs...>]

L.S.

The development branch for project "skip_entire_test_files" is now ready for
merging into the target branches trunk and core-9-0-branch [*].

Unless someone raises founded objections in the meantime, I will carry out the
intended merge on next Wednesday (or the first opportunity for me thereafter),
but no earlier than that trunk is in good order, i.e. the Tk test suite passes
for trunk on Github CI for all platforms.

Regards,
Erik Leunissen.
--

[*] Notes
     -----
     - The previous post in this thread holds a summary of the project's results.
     - No comments were received during the stage of final review, either on this
       mailing list or at the project's ticket.
     - Github CI is fine with the changes on the development branch
     - Useful links:
       * the project's ticket:

           https://core.tcl-lang.org/tk/tktview/83eed90f93

       * the complete diff w.r.t. trunk:

           https://core.tcl-lang.org/tk/vdiff?branch=skip_entire_test_files

       * the timeline of the development branch:

           https://core.tcl-lang.org/tk/timeline?r=skip_entire_test_files

       * the results of Tk test suite runs on Github CI:

           https://github.com/tcltk/tk/actions?query=branch%3Askip_entire_test_files

[TCLCORE] 11 November Tcl monthly virtual meetup notice

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

The next meetup will be on Tuesday 11 November 2025 at [clock format 1762887600]
- Tuesday 11am US West, 1pm US Central, 2pm US East, 7pm UTC, 7pm UK,
8pm Western Europe, Wednesday 12:30am India, 3am Australia West /
Singapore / China, 4am Japan, 6am Australia East, 8am New Zealand.

Details (including how to connect) are available via
https://wiki.tcl-lang.org/page/Monthly+Virtual+Meetup

Colin.

Re: [TCLCORE] [Ext] Re: [=] for concise expressions (was Re: TIP 672 Implementation Complete - Ready for Sponsorship)

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

Hi Eric

Thank you for your effort to bring this topic forward.
Imho Colin's syntax is even better as the let version.
I hope one of your proposals will make it into the core.

Regards
rene

Von: EricT <tw...@gm...>
Gesendet: Freitag, 7. November 2025 21:35
An: Zaumseil René <RZa...@kk...>
Cc: tc...@ro...; tcl...@li...
Betreff: Re: [TCLCORE] [Ext] Re: [=] for concise expressions (was Re: TIP 672 Implementation Complete - Ready for Sponsorship)

Rene,

That's the beauty of making bytecode compilation official - we DON'T have to agree on syntax! With a supported tcl::bytecode API, each of us can create our own Design-Specific Language for our own needs. No more "one size fits all" debates that go nowhere.

That said, I think you might find Colin's approach already fits your needs quite well. Here's how your examples would look:

Multiple assignments:

# Your let syntax
let {x 1+2 y 3*4 z $x+$y}

# Colin's syntax (bare variables, no $)
: {x = 1+2
   y = 3*4
   z = x+y}


For my own taste, I've here aliased = to : since = as the command seems to clash visually with = for assignment, especially in cases like a = b = c = d. The semicolon requires braces since it's special to Tcl, but by mapping newlines to semicolons internally, multiple statements work naturally in braced blocks as shown above.

Returning multiple values:

# With a simple helper function
proc tcl::mathfunc::gather {args} { list {*}$args }

# Your canvas example
.c create text {*}[= gather(x+1, y+1)] -text a

# Or inline
= {tx = x+1 ; ty = y+1 ; gather(tx, ty)}


Your calculations example:

set i 0.5
= {x = sin(i)
   y = cos(i) + x
   z = x + y}


The key differences: bare variables (no $), explicit = for assignment, semicolon (or newline) to separate multiple expressions, and gather() for multiple returns. But it's all extensible - add your own functions to tcl::mathfunc:: and they're automatically available.

If you prefer different syntax, you can build your let command using the same bytecode infrastructure. That's the whole point - multiple DSLs coexisting, each optimized by bytecode caching.


Eric

On Fri, Nov 7, 2025 at 6:19 AM Zaumseil René via Tcl-Core <tcl...@li...<mailto:tcl...@li...>> wrote:
Hi Eric

I really like the tcl::unsupported::assemble approach.
It opens the way to add more commands/sugar to tcl itself without
having to hard code it in C.

Now we have to agree on the syntax. May be a wiki page with a summary of the different proposals?


Regards
rene


Von: EricT <tw...@gm...<mailto:tw...@gm...>>
Gesendet: Freitag, 7. November 2025 01:03
An: Zaumseil René <RZa...@kk...<mailto:RZa...@kk...>>; tcl...@li...<mailto:tcl...@li...>
Betreff: Re: [TCLCORE] [Ext] Re: [=] for concise expressions (was Re: TIP 672 Implementation Complete - Ready for Sponsorship)


Hi Rene,



I was experimenting with your TIP 674 prototype and realized both your let command and Colin's expression evaluator share something important: they could both be implemented in pure Tcl if tcl::unsupported::assemble were promoted to supported status with handle-based caching.



This would avoid another round of "expr wars" where lack of consensus leaves us with nothing. Instead of debating whose syntax is better, we'd each have the power to create our own Design-Specific Language. With bytecode caching, pure Tcl implementations achieve C extension performance - Colin's evaluator runs at 1.8 microseconds, nearly as fast as expr.



Why does this matter for your TIP? If let performs just as well in Tcl as in C, why require a C implementation at all? C extensions take weeks to develop, need binaries for every platform/architecture combination, and ultimately call the same bytecode infrastructure that assemble uses. A supported bytecode API would make both proposals - and many others - viable without C.



Perhaps we should advocate together for making the bytecode compilation infrastructure officially supported, rather than competing for TIP approval on individual commands?



Best,

Eric


On Wed, Nov 5, 2025 at 11:31 PM Zaumseil René via Tcl-Core <tcl...@li...<mailto:tcl...@li...>> wrote:
Hello

I also like the = approach as a new expr command without need of $ for variables.
But I'm not sure about the currently proposed syntax.
Is it "= 1 + 2" or "= 1+2" (with or without spaces)?
If it is the later then I would propose to use some of the syntax of the "let" from tip 674.

Some syntax ideas:
"= 1+2" return 3, simple case
"= a 1+2 b 2+4 c a+b" return {3 6 9} and set a,b,c
"= 1+2 = 2+4" return {3 6}
And may be some others…

Regards
rene
Von: EricT <tw...@gm...<mailto:tw...@gm...>>
Gesendet: Mittwoch, 5. November 2025 23:22
An: Colin Macleod <col...@ya...<mailto:col...@ya...>>; tcl...@li...<mailto:tcl...@li...>
Betreff: [Ext] Re: [TCLCORE] [=] for concise expressions (was Re: TIP 672 Implementation Complete - Ready for Sponsorship)


Hi Colin,



I've successfully modified your amazing code to handle arrays. In doing so, I also found 2 other issues, one is with your Boolean check, the other with your function name check, both because of [string is] issues.



- Boolean check: `$token eq "false" || $token eq "true"` (was `[string is boolean $token]` - treated 'f','n', 't', 'y', etc. variables as boolean false, no, true, yes, ...)



- Function check: `[regexp {^[[:alpha:]]} $token]` (was `[string is alpha $token]` - broke log10, atan2)





here's the code for arrays:



    # Function call or array reference?

    set nexttok [lindex $::tokens $::tokpos]

    if {$nexttok eq "(" && [regexp {^[[:alpha:]]} $token]} {

        set fun [namespace which tcl::mathfunc::$token]

        if {$fun ne {}} {

            # It's a function

            incr ::tokpos

            set opcodes "push $fun; "

            append opcodes [parseFuncArgs]

            return $opcodes

        } else {

            # Not a function, assume array reference

            incr ::tokpos

            set opcodes "push $token; "

            # Parse the index expression - leaves VALUE on stack

            append opcodes [parse 0]

            # Expect closing paren

            set closing [lindex $::tokens $::tokpos]

            if {$closing ne ")"} {

                error "Calc: expected ')' but found '$closing'"

            }

            # Stack now has: [arrayname, indexvalue]

            incr ::tokpos

            append opcodes "loadArrayStk; "

            return $opcodes

        }

    }





In addition, there has indeed been some changes in the bytecode, land and lor are no longer supported in 9.0 although they work in 8.6.



I had an AI generate some 117 test cases, which all pass on 8.6 and 111 on 9.x (the land/lor not being tested in 9.x).



Colin, with your permission, I can post the code as a new file, with all the test cases, say on a repository at github.



I think a new TIP is worth considering; one that promotes assemble to a supported form, with a compile and handle approach to avoid the time parsing the ascii byte code text. I think that this would be great for your = command, but also quite useful for others who might want to create their own little languages.



By doing it this way, it remains pure tcl, and avoids all the problems with different systems and hardware that a binary extension would create. In the end, I believe your code can achieve performance parity with expr. Not only does it remove half the [expr {...}] baggage, but all the $'s too! So much easier on these old eyes.



Regards,



Eric


On Tue, Nov 4, 2025 at 1:06 PM EricT <tw...@gm...<mailto:tw...@gm...>> wrote:
Hi Colin,

Hmmm, why can't you do bareword on $a(b) as a(b) you just need to do an uplevel to see if a is a variable, if not, it would have to be a function. True?

% tcl::unsupported::disassemble script {set a [expr {$b($c)}] }
snip
  Command 2: "expr {$b($c)}..."
    (2) push1 1 # "b"
    (4) push1 2 # "c"
    (6) loadStk
    (7) loadArrayStk
    (8) tryCvtToNumeric
    (9) storeStk
    (10) done
This doesn't look too much different from what you are producing.

I think what's really needed here is a TIP that would open up the bytecode a bit so you don't need to use an unsupported command. And then maybe even have a new command to take the string byte code you are now producing and return a handle to a cached version that was probably equivalent to the existing bytecode. Then your cache array would be

 set cache($exp) $handle

Instead of it having to parse the text, it could be as fast as bytecode. You'd likely be just as fast as expr, and safe as well, since you can't pass a string command in where the bareword is required:

 % set x {[pwd]}
[pwd]
 % = sqrt(x)
exp= |sqrt(x)| code= |push ::tcl::mathfunc::sqrt; push x; loadStk; invokeStk 2; | ifexist: 0
expected floating-point number but got "[pwd]"
I think you really have something here, perhaps this is the best answer yet to slay the expr dragon!

Regards,

Eric


On Tue, Nov 4, 2025 at 6:52 AM Colin Macleod via Tcl-Core <tcl...@li...<mailto:tcl...@li...>> wrote:

Hi Eric,

That's very neat!

Yes, a pure Tcl version could go into TclLib. I still think it may be worth trying a C implementation though.  The work-around that's needed for array references [= 2* $a(b)] would defeat the caching, so it would be good to speed up the parsing if possible.  Also I think your caching may be equivalent to doing byte-compilation, in which case it may make sense to use the framework which already exists for that.

Colin.
On 04/11/2025 01:18, EricT wrote:
that is:

if {[info exist ::cache($exp)]} {
    tailcall ::tcl::unsupported::assemble $::cache($exp)
}

(hate gmail!)


On Mon, Nov 3, 2025 at 5:17 PM EricT <tw...@gm...<mailto:tw...@gm...>> wrote:
and silly of me, it should be:
if {[info exist ::cache($exp)]} {
    tailcall ::tcl::unsupported::assemble $::cache($exp)
}

On Mon, Nov 3, 2025 at 4:50 PM EricT <tw...@gm...<mailto:tw...@gm...>> wrote:
With a debug line back in plus the tailcall:

proc = args {
    set exp [join $args]
    if { [info exist ::cache($exp)] } {
         return [tailcall  ::tcl::unsupported::assemble $::cache($exp)]
    }
    set tokens [tokenise $exp]
    deb1 "TOKENS = '$tokens'"
    set code [compile $tokens]
    deb1 "GENERATED CODE:\n$code\n"
    puts "exp= |$exp| code= |$code| ifexist: [info exist ::cache($exp)]"
    set ::cache($exp) $code
    uplevel [list ::tcl::unsupported::assemble $code]
}

% set a 5
5
 % set b 10
10
 % = a + b
exp= |a + b| code= |push a; loadStk; push b; loadStk; add; | ifexist: 0
15
% = a + b
15

% time {= a + b} 1000
1.73 microseconds per iteration
Faster still!

I thought the uplevel was needed to be able to get the local variables, seems not.

 % proc foo arg {set a 5; set b 10; set c [= a+b+arg]}
 % foo 5
exp= |a+b+arg| code= |push a; loadStk; push b; loadStk; add; push arg; loadStk; add; | ifexist: 0
20
% foo 5
20

 % proc foo arg {global xxx; set a 5; set b 10; set c [= a+b+arg+xxx]}

 % set xxx 100
100
 % foo 200
315
 % time {foo 200} 10000
2.1775 microseconds per iteration

 % parray cache
cache(a + b)       = push a; loadStk; push b; loadStk; add;
cache(a+b+arg)     = push a; loadStk; push b; loadStk; add; push arg; loadStk; add;
cache(a+b+arg+xxx) = push a; loadStk; push b; loadStk; add; push arg; loadStk; add; push xxx; loadStk; add;

Very Impressive, great job Colin! Great catch Don!

Eric




On Mon, Nov 3, 2025 at 4:22 PM Donald Porter via Tcl-Core <tcl...@li...<mailto:tcl...@li...>> wrote:
Check what effect replacing [uplevel] with [tailcall] has.

On Nov 3, 2025, at 7:13 PM, EricT <tw...@gm...<mailto:tw...@gm...>> wrote:

Subject: Your bytecode expression evaluator - impressive results with caching!

Hey Colin:

I took a look at your bytecode-based expression evaluator and was intrigued by the approach. I made a small modification to add caching and the results are really impressive. Here's what I changed:

proc = args {
    set exp [join $args]
    if {[info exist ::cache($exp)]} {
        return [uplevel [list ::tcl::unsupported::assemble $::cache($exp)]]
    }
    set tokens [tokenise $exp]
    deb1 "TOKENS = '$tokens'"
    set code [compile $tokens]
    deb1 "GENERATED CODE:\n$code\n"
    set ::cache($exp) $code
    uplevel [list ::tcl::unsupported::assemble $code]
}

The cache is just a simple array lookup - one line to store, one line to retrieve. But the performance impact is huge:

Performance Tests

Without caching
% time {= 1 + 2} 1000
24.937 microseconds per iteration

With caching
% time {= 1 + 2} 1000
1.8 microseconds per iteration

That's a 13x speedup! The tokenize and parse steps were eating about 92% of the execution time.

The Real Magic: Bare Variables + Caching

What really impressed me is how well your bare variable feature synergizes with caching:

% set a 5
5
% set b 6
6
% = a + b
11
% time {= a + b} 1000
2.079 microseconds per iteration

Now change the variable values
% set a 10
10
% = a + b
16
% time {= a + b} 1000
2.188 microseconds per iteration

The cache entry stays valid even when the variable values change! Why? Because the bytecode stores variable names, not values:

push a; loadStk; push b; loadStk; add;

The loadStk instruction does runtime lookup, so:
- Cache key is stable: "a + b"
- Works for any values of a and b
- One cache entry handles all value combinations

Compare this to if we used $-substitution:

= $a + $b    # With a=5, b=6 becomes "5 + 6"
= $a + $b    # With a=10, b=6 becomes "10 + 6" - different cache key!

Every value change would create a new cache entry or worse, a cache miss.

Comparison to Other Approaches

Tcl's expr:              about 0.40 microseconds
Direct C evaluator:      about 0.53 microseconds
Your cached approach:    about 1.80 microseconds
Your uncached approach:  about 24.9 microseconds

With caching, you're only 3-4x slower than a direct C evaluator.


My Assessment

Your design is excellent. The bare variable feature isn't just syntax sugar - it's essential for good cache performance. The synergy between:

1. Bare variables leading to stable cache keys
2. Runtime lookup keeping cache hot
3. Simple caching providing dramatic speedup

makes this really elegant.

My recommendation: Keep it in Tcl! The implementation is clean, performance is excellent (1.8 microseconds is plenty fast), and converting to C would add significant complexity for minimal gain (maybe getting to about 1.0 microseconds).

The Tcl prototype with caching is actually the right solution here. Sometimes the prototype IS the product!

Excellent work on this. The bytecode approach really shines with caching enabled.

On Sun, Nov 2, 2025 at 10:14 AM Colin Macleod via Tcl-Core <tcl...@li...<mailto:tcl...@li...>> wrote:

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...><mailto:tcl...@li...>
Date: 02/11/2025 08:13 (GMT+00:00)
To: Pietro Cerutti <ga...@ga...><mailto:ga...@ga...>
Cc: tcl...@li...<mailto:tcl...@li...>, av...@lo...<mailto: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...<mailto:Tcl...@li...>
https://lists.sourceforge.net/lists/listinfo/tcl-core
_______________________________________________
Tcl-Core mailing list
Tcl...@li...<mailto:Tcl...@li...>
https://lists.sourceforge.net/lists/listinfo/tcl-core

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


_______________________________________________

Tcl-Core mailing list

Tcl...@li...<mailto:Tcl...@li...>

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

Re: [TCLCORE] Merge of branch tka11y into trunk redefines tcltest built-in constraint "win"

[Erik L. <el...@xs...>]

On 11/9/25 19:03, Kevin Walzer wrote:
> 
> On 11/9/25 11:56 AM, Kevin Walzer wrote:
>> What’s the fix? Just delete the redundant entry?
> Just committed a fix that does just that.

Yep. That resolves the issue.
Erik.

  Thanks for catching it.
> 
> 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] Merge of branch tka11y into trunk redefines tcltest built-in constraint "win"

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

On 11/9/25 11:56 AM, Kevin Walzer wrote:
> What’s the fix? Just delete the redundant entry?
Just committed a fix that does just that. Thanks for catching it.

Re: [TCLCORE] Merge of branch tka11y into trunk redefines tcltest built-in constraint "win"

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

What’s the fix? Just delete the redundant entry?

> On Nov 9, 2025, at 10:07 AM, Erik Leunissen <el...@xs...> wrote:
> 
> On 11/9/25 15:40, Kevin Walzer wrote:
> 
>> Feel free to revert to whatever you deem appropriate.
> 
> Thanks, but no.
> I feel that it is not up to me to do that.
> 
> Erik Leunissen.
> --
> 

Re: [TCLCORE] Merge of branch tka11y into trunk redefines tcltest built-in constraint "win"

[Erik L. <el...@xs...>]

On 11/9/25 15:40, Kevin Walzer wrote:

> Feel free to revert to whatever you deem appropriate.

Thanks, but no.
I feel that it is not up to me to do that.

Erik Leunissen.
--

Re: [TCLCORE] Merge of branch tka11y into trunk redefines tcltest built-in constraint "win"

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

That is a relic from when I was trying to add direct testing of accessibility in the test suite. I abandoned that effort. Feel free to revert to whatever you deem appropriate. 

> On Nov 9, 2025, at 9:33 AM, Erik Leunissen <el...@xs...> wrote:
> 
> The redefinition occurs here:
> 
>    https://core.tcl-lang.org/tk/artifact?name=211ceb01b3dc7b76&ln=30
> 
> 
> Note that a test constraint with definition:
> 
>        [expr {[tk windowingsystem] eq "win32"}]
> 
> already exists by the name "win32" (defined two lines before).
> Why not use that readily available test constraint?
> 
> Sincerely,
> Erik Leunissen.
> --
> 

[TCLCORE] Merge of branch tka11y into trunk redefines tcltest built-in constraint "win"

[Erik L. <el...@xs...>]

The redefinition occurs here:

     https://core.tcl-lang.org/tk/artifact?name=211ceb01b3dc7b76&ln=30


Note that a test constraint with definition:

         [expr {[tk windowingsystem] eq "win32"}]

already exists by the name "win32" (defined two lines before).
Why not use that readily available test constraint?

Sincerely,
Erik Leunissen.
--

Re: [TCLCORE] [Ext] Re: [=] for concise expressions (was Re: TIP 672 Implementation Complete - Ready for Sponsorship)

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

Hi Don:

I understand your concern. But if history is any guide, it's far easier to
get tcl to stay the same than to change. I doubt there will be any
incompatibilities with the use of the assemble command, at least not in my
lifetime. And if I were to live to see it, I expect I'll just ask my robot
to fix the code. The one I use now is a very good C and Tcl programmer. And
as Perry White said to Lois Lane when he hired Clark Kent: In my 40 years
in this business, he's the fastest typist I've ever seen.

So, I've put the final touches on the Colin fork, putting everything except
one global into a Calc:: namespace. It works just fine now in 8.6 and 9.x.
and so I'll leave this debate to others. I want to thank everyone for their
comments. It has been quite an interesting month.

Eric


On Sat, Nov 8, 2025 at 3:02 PM Donald Porter via Tcl-Core <
tcl...@li...> wrote:

> One of the reasons [assemble] is unsupported is because no one is tasked
> with keeping it up to date with new bytecodes.
>
> There is considerable value in not exposing and committing to every
> internal detail of your software.
>
> DGP
>
>
> On Nov 8, 2025, at 5:50 PM, EricT <tw...@gm...> wrote:
>
> Did you try this on 8.6 or 9.x, if the error message is to be believed,
> then swap is new to 9.x.
>
> Eric
>
> On Sat, Nov 8, 2025 at 7:03 AM Colin Macleod via Tcl-Core <
> tcl...@li...> wrote:
>
>> Similarly, if we restrict to numeric operands, an alternative to `land`
>> would be `not; swap; not; bitor; not` .  However when I try this
>> ::tcl::unsupported::assemble tells me `swap` is not a valid instruction,
>> although it is listed in generic/tclAssembly.c  😮
>>
>> Colin.
>> On 08/11/2025 08:45, Colin Macleod via Tcl-Core wrote:
>>
>> I haven't tested this, but a simpler alternative to `lor` could be
>> `bitor; not; not` .
>>
>> Colin.
>> On 08/11/2025 05:56, EricT wrote:
>>
>> HI all,
>>
>> Well it isn't pretty, but now we have an equivalent test for land/lor,
>>
>> Took a few go-arounds with gemini to get the logic right, but here's the
>> replacements that work in both 8.6 and 9.x
>>
>>   foreach {op prec code} {
>>     )  0 -
>>     ,  0 -
>>     =  0 -
>>     ?  1 -
>>     :  1 -
>>     || 2 {jumpTrue true_res; jumpFalse pop_A; push 1; jump end_res; label
>> pop_A; push 0; jump end_res; label true_res; pop; push 1; label end_res}
>>     && 3 {jumpFalse pop_A; jumpFalse false_res; push 1; jump end_res;
>> label pop_A; pop; label false_res; push 0; label end_res}
>>     |  4 bitor
>>     ^  5 bitxor
>>     &  6 bitand
>>     ......
>>
>>
>> Not sure why they bothered to remove land/lor, couldn't have saved much
>> by removing it. Now that's I guess what the developers will not like, that
>> they can't just remove it if it goes public. But it was after all an easy
>> fix. The other codes are unlikely to go away any time soon I would think.
>> And a side by side compare shows that the only other differences, at least
>> according to the list output by assemble if you give it an invalid one, are
>> that these are all new to 9.x
>>
>> dictGetDef
>>  dictPut
>>  dictRemove
>>  isEmpty
>>  jumpTableNum
>>  strge
>>  strgt
>>  strle
>>  strlt
>>  swap
>>  tclooId
>>
>> Stack machines are kinda fun. And the assembler is actually pretty
>> friendly, it knew in advance that I was going to have a stack imbalance,
>> and then the next try gave a stack underrun, but it simply threw an error
>> with a nice message. Very cool I'd say. They ain't kidding when they say, "
>> Gemini can make mistakes, so double-check it ". Anyone care to verify
>> these, though my 146 + 8 more for the logic test cases are all working on
>> both 8.6 and  9.x.
>>
>> There is one thing, the code we're generating has to push all
>> variable names, unlike expr where the compiler is smarter and has locals
>> that it doesn't have to lookup by name each time. We can't use a peephole
>> optimiser, like the compiler, so expr will always have that advantage. But
>> we're in the same ballpark at least.
>>
>> Eric
>>
>>
>> On Fri, Nov 7, 2025 at 5:44 PM Phillip Brooks <phi...@um...> wrote:
>>
>>> I would like to see something like this in the core.  Then, there is no
>>> concern about using the undocumented interface.
>>>
>>> Phil
>>>
>>> On Fri, Nov 7, 2025 at 5:40 PM Steve Landers <st...@di...>
>>> wrote:
>>>
>>>> I am very positive about Colin's approach, especially with the speedups
>>>> you (Eric) have recommended.  In my opinion it offers the best hope of
>>>> improving the expr command without breaking code or introducing Lots of
>>>> Interminably Silly Parentheses (see what I did there?).
>>>>
>>>> As for bytecode changes,  as Phil notes they come with the risk of
>>>> making the solution release-dependent but I don't think that should be seen
>>>> as a show-stopper given the value of an improved expr.
>>>>
>>>> Just my 2c worth
>>>>
>>>> -- Steve
>>>> On 8 Nov 2025 at 9:06 AM +0800, EricT <tw...@gm...>, wrote:
>>>>
>>>> Philip:
>>>>
>>>> Well, maybe it's a good thing that I don't have any tct votes. But now
>>>> I have some pure tcl, that runs very fast and finally I can put the expr
>>>> dragon to rest. I have several versions of tcl, and many of Ashok's great
>>>> tclkit's bundled with twapi. I hope he finds a way to create more,
>>>> especially for 9.x. I have some utilities that for some forgotten reason
>>>> still need an older 8.6, and so that's how they launch.
>>>>
>>>> If you want to try my latest fork of Colin's masterpiece, you can just
>>>> tclsh it and then take a look at the bytecode, as it dumps the cache at the
>>>> end. There are now 140 test cases you can look through as examples of
>>>> usage.  The last 10 also use : as the command name, which I think of as a
>>>> slimmer alias of = that just seems to look right to my eyes. But = works as
>>>> well.
>>>>
>>>> Here's the very latest:
>>>>
>>>> https://github.com/rocketship88/colin-parser
>>>>
>>>> Eric
>>>>
>>>>
>>>> On Fri, Nov 7, 2025 at 4:16 PM Phillip Brooks <phi...@um...>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Fri, Nov 7, 2025 at 2:14 PM EricT <tw...@gm...> wrote:
>>>>>
>>>>>> Hi Phillip:
>>>>>>
>>>>>> In going from tcl 8.6 to tcl 9.0 the only things that broke, at least
>>>>>> where Colin's program is concerned, were land and lor, which are no longer
>>>>>> supported. If the bytecode were to have to support those two because they
>>>>>> had been made public, I don't see the big harm. In 8.6 they'd already gone
>>>>>> to a jump based arrangement for short circuiting. So, in 9.x they just
>>>>>> removed these 2 instructions.
>>>>>>
>>>>>
>>>>> The harm is that the bytecode is currently allowed to change
>>>>> completely from release to release.   This allows for reorganization and
>>>>> optimization that would otherwise be impossible.  The way you are using it
>>>>> is, I think, safe since you only ever create and run it in the same
>>>>> session.  If opened up for general use, people might try to save it to a
>>>>> file, and then use that on a different release.   Others are more expert in
>>>>> this area than I am, though.
>>>>>
>>>>> Phil
>>>>>
>>>>>> _______________________________________________
>>>>> 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
>>>>
>>>> _______________________________________________
>>> Tcl-Core mailing list
>>> Tcl...@li...
>>> https://lists.sourceforge.net/lists/listinfo/tcl-core
>>>
>>
>>
>> _______________________________________________
>> Tcl-Core mailing lis...@li...://lists.sourceforge.net/lists/listinfo/tcl-core
>>
>>
>>
>> _______________________________________________
>> Tcl-Core mailing lis...@li...://lists.sourceforge.net/lists/listinfo/tcl-core
>>
>> _______________________________________________
>> 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
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

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

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

On 11/1/25 8:36 PM, Kevin Walzer wrote:
> 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


TIP 733:

YES: MC, AK, SL, AN, JN, HO, KW
NO: None
PRESENT: None

TIP 733 is APPROVED. Thanks to all for your input, and support.

--Kevin

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

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

Update on the test failures:

On 11/7/25 9:29 PM, Kevin Walzer wrote:
>>
>> On MacOS:
>> safe.test
>> ==== safe-1.1 Safe Tk loading into an interpreter FAILED
>> ==== Contents of test case:
>> safe::loadTk [safe::interpCreate a]
>> safe::interpDelete a
>> set x {}
>> return $x
>> ---- Test generated error; Return code was: 1
>> ---- Return code should have been one of: 0 2
>> ---- errorInfo: Can't find a usable tk.tcl in the following directories:
>> {$p(:12:)}
>> .......
>> Tests ended at 2025-11-07 08:00:25 UTC
>> all.tcl: Total 10050 Passed 8791 Skipped 1223 Failed 36
>> Sourced 98 Test Files.
>> Files with failing tests: safe.test safePrimarySelection.test tk.test
> I can see this error on macOS, but it baffles me how the accessibility 
> code could be corrupting the tk_library path. When we saw this error 
> on prior tests just creating a child interp, you helped me add some 
> code to accessibility.tcl that essentially returned an empty command 
> set for child interpreters. That doesn't seem to be good enough here. 
> I also tried skipping loading accessibility.tcl altogether if we were 
> in a safe interp, but that doesn't have any effect. You had mentioned 
> that this error was probably fixable - I would love any ideas you 
> might have.
I've committed a fix that corrects this, and safe interps now load 
correctly on macOS/Aqua. A mapping between the "exit" command and the 
::tk::mac::Quit command was the culprit - I only found this by diffing 
trunk and the tka11y branch, and noticing that this mapping was NOT 
present in trunk.
>>
>>
>> With --disable-aqua:
>> DYLD_FALLBACK_LIBRARY_PATH="`pwd`:/Users/runner/work/tk/tk/tcl/unix:${DYLD_FALLBACK_LIBRARY_PATH}"; 
>>
>> export DYLD_FALLBACK_LIBRARY_PATH;
>> TCL_LIBRARY=/Users/runner/work/tk/tk/tcl/library; export TCL_LIBRARY;
>> TK_LIBRARY=/Users/runner/work/tk/tk/tk/library; export TK_LIBRARY;
>> ./tktest /Users/runner/work/tk/tk/tk/unix/../tests/all.tcl
>> /bin/sh: line 1: 19218 Segmentation fault: 11 ./tktest
>> /Users/runner/work/tk/tk/tk/unix/../tests/all.tcl
>> make: *** [test-classic] Error 139
>> killing process 19155...
>> Error: Failure during Test (classic)
>> Error: Process completed with exit code 1.
> I'm inclined to call this an invalid test because accessiblity will 
> never run under XQuartz on macOS - the dependencies such as dbus just 
> aren't there.
I was able to correct this as well. Wish no longer crashes on startup. 
Attempting to load accessibility.tcl under XQuartz just caused things to 
go haywire, so I'm disabling it altogether. The man page has been 
updated to note that accessibility is NOT supported under XQuartz.
>>
>> On Linux, with --enable-symbols:
>> LD_LIBRARY_PATH="`pwd`:/home/runner/work/tk/tk/tcl/unix:${LD_LIBRARY_PATH}"; 
>>
>> export LD_LIBRARY_PATH;
>> TCL_LIBRARY=/home/runner/work/tk/tk/tcl/library; export TCL_LIBRARY;
>> TK_LIBRARY=/home/runner/work/tk/tk/tk/library; export TK_LIBRARY;
>> ./tktest /home/runner/work/tk/tk/tk/unix/../tests/all.tcl
>> make: *** [Makefile:734: test-classic] Segmentation fault (core dumped)
>> Error: Process completed with exit code 2.
>
> I am not able to reproduce this. The test suite runs just fine on my 
> Debian installation. If I got this a bug report, I would close it as 
> "works for me." So I'm not sure what to do here.
>
Still can't reproduce this, so I'm not going to expend further effort on 
it.

Two out of three ain't bad.

--Kevin

Re: [TCLCORE] [Ext] Re: [=] for concise expressions (was Re: TIP 672 Implementation Complete - Ready for Sponsorship)

[Donald P. <d.g...@co...>]

One of the reasons [assemble] is unsupported is because no one is tasked with keeping it up to date with new bytecodes.

There is considerable value in not exposing and committing to every internal detail of your software.

DGP


> On Nov 8, 2025, at 5:50 PM, EricT <tw...@gm...> wrote:
> 
> Did you try this on 8.6 or 9.x, if the error message is to be believed, then swap is new to 9.x.
> 
> Eric
> 
> On Sat, Nov 8, 2025 at 7:03 AM Colin Macleod via Tcl-Core <tcl...@li... <mailto:tcl...@li...>> wrote:
>> Similarly, if we restrict to numeric operands, an alternative to `land` would be `not; swap; not; bitor; not` .  However when I try this ::tcl::unsupported::assemble tells me `swap` is not a valid instruction, although it is listed in generic/tclAssembly.c  😮
>> 
>> Colin.
>> 
>> On 08/11/2025 08:45, Colin Macleod via Tcl-Core wrote:
>>> I haven't tested this, but a simpler alternative to `lor` could be `bitor; not; not` .
>>> 
>>> Colin.
>>> 
>>> On 08/11/2025 05:56, EricT wrote:
>>>> HI all, 
>>>> 
>>>> Well it isn't pretty, but now we have an equivalent test for land/lor, 
>>>> 
>>>> Took a few go-arounds with gemini to get the logic right, but here's the replacements that work in both 8.6 and 9.x
>>>> 
>>>>   foreach {op prec code} {
>>>>     )  0 -
>>>>     ,  0 -
>>>>     =  0 -
>>>>     ?  1 -
>>>>     :  1 -
>>>>     || 2 {jumpTrue true_res; jumpFalse pop_A; push 1; jump end_res; label pop_A; push 0; jump end_res; label true_res; pop; push 1; label end_res}
>>>>     && 3 {jumpFalse pop_A; jumpFalse false_res; push 1; jump end_res; label pop_A; pop; label false_res; push 0; label end_res}
>>>>     |  4 bitor
>>>>     ^  5 bitxor
>>>>     &  6 bitand
>>>>     ......
>>>> 
>>>> 
>>>> Not sure why they bothered to remove land/lor, couldn't have saved much by removing it. Now that's I guess what the developers will not like, that they can't just remove it if it goes public. But it was after all an easy fix. The other codes are unlikely to go away any time soon I would think. And a side by side compare shows that the only other differences, at least according to the list output by assemble if you give it an invalid one, are that these are all new to 9.x
>>>> 
>>>> dictGetDef
>>>>  dictPut
>>>>  dictRemove
>>>>  isEmpty
>>>>  jumpTableNum
>>>>  strge
>>>>  strgt
>>>>  strle
>>>>  strlt
>>>>  swap
>>>>  tclooId
>>>> 
>>>> Stack machines are kinda fun. And the assembler is actually pretty friendly, it knew in advance that I was going to have a stack imbalance, and then the next try gave a stack underrun, but it simply threw an error with a nice message. Very cool I'd say. They ain't kidding when they say, " Gemini can make mistakes, so double-check it ". Anyone care to verify these, though my 146 + 8 more for the logic test cases are all working on both 8.6 and  9.x.
>>>> 
>>>> There is one thing, the code we're generating has to push all variable names, unlike expr where the compiler is smarter and has locals that it doesn't have to lookup by name each time. We can't use a peephole optimiser, like the compiler, so expr will always have that advantage. But we're in the same ballpark at least.
>>>> 
>>>> Eric
>>>> 
>>>> 
>>>> On Fri, Nov 7, 2025 at 5:44 PM Phillip Brooks <phi...@um... <mailto:phi...@um...>> wrote:
>>>>> I would like to see something like this in the core.  Then, there is no concern about using the undocumented interface. 
>>>>> 
>>>>> Phil
>>>>> 
>>>>> On Fri, Nov 7, 2025 at 5:40 PM Steve Landers <st...@di... <mailto:st...@di...>> wrote:
>>>>>> I am very positive about Colin's approach, especially with the speedups you (Eric) have recommended.  In my opinion it offers the best hope of improving the expr command without breaking code or introducing Lots of Interminably Silly Parentheses (see what I did there?).
>>>>>> 
>>>>>> As for bytecode changes,  as Phil notes they come with the risk of making the solution release-dependent but I don't think that should be seen as a show-stopper given the value of an improved expr.
>>>>>> 
>>>>>> Just my 2c worth
>>>>>> 
>>>>>> -- Steve
>>>>>> On 8 Nov 2025 at 9:06 AM +0800, EricT <tw...@gm... <mailto:tw...@gm...>>, wrote:
>>>>>>> Philip:
>>>>>>> 
>>>>>>> Well, maybe it's a good thing that I don't have any tct votes. But now I have some pure tcl, that runs very fast and finally I can put the expr dragon to rest. I have several versions of tcl, and many of Ashok's great tclkit's bundled with twapi. I hope he finds a way to create more, especially for 9.x. I have some utilities that for some forgotten reason still need an older 8.6, and so that's how they launch.
>>>>>>> 
>>>>>>> If you want to try my latest fork of Colin's masterpiece, you can just tclsh it and then take a look at the bytecode, as it dumps the cache at the end. There are now 140 test cases you can look through as examples of usage.  The last 10 also use : as the command name, which I think of as a slimmer alias of = that just seems to look right to my eyes. But = works as well. 
>>>>>>> 
>>>>>>> Here's the very latest:
>>>>>>> 
>>>>>>> https://github.com/rocketship88/colin-parser
>>>>>>> 
>>>>>>> Eric
>>>>>>> 
>>>>>>> 
>>>>>>> On Fri, Nov 7, 2025 at 4:16 PM Phillip Brooks <phi...@um... <mailto:phi...@um...>> wrote:
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Fri, Nov 7, 2025 at 2:14 PM EricT <tw...@gm... <mailto:tw...@gm...>> wrote:
>>>>>>>>> Hi Phillip:
>>>>>>>>> 
>>>>>>>>> In going from tcl 8.6 to tcl 9.0 the only things that broke, at least where Colin's program is concerned, were land and lor, which are no longer supported. If the bytecode were to have to support those two because they had been made public, I don't see the big harm. In 8.6 they'd already gone to a jump based arrangement for short circuiting. So, in 9.x they just removed these 2 instructions.
>>>>>>>> 
>>>>>>>> The harm is that the bytecode is currently allowed to change completely from release to release.   This allows for reorganization and optimization that would otherwise be impossible.  The way you are using it is, I think, safe since you only ever create and run it in the same session.  If opened up for general use, people might try to save it to a file, and then use that on a different release.   Others are more expert in this area than I am, though. 
>>>>>>>> 
>>>>>>>> Phil
>>>>>>>> _______________________________________________
>>>>>>>> Tcl-Core mailing list
>>>>>>>> Tcl...@li... <mailto:Tcl...@li...>
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/tcl-core
>>>>>>> _______________________________________________
>>>>>>> Tcl-Core mailing list
>>>>>>> Tcl...@li... <mailto:Tcl...@li...>
>>>>>>> https://lists.sourceforge.net/lists/listinfo/tcl-core
>>>>> _______________________________________________
>>>>> Tcl-Core mailing list
>>>>> Tcl...@li... <mailto:Tcl...@li...>
>>>>> https://lists.sourceforge.net/lists/listinfo/tcl-core
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Tcl-Core mailing list
>>>> Tcl...@li... <mailto:Tcl...@li...>
>>>> https://lists.sourceforge.net/lists/listinfo/tcl-core
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Tcl-Core mailing list
>>> Tcl...@li... <mailto:Tcl...@li...>
>>> https://lists.sourceforge.net/lists/listinfo/tcl-core
>> _______________________________________________
>> Tcl-Core mailing list
>> Tcl...@li... <mailto: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] [Ext] Re: [=] for concise expressions (was Re: TIP 672 Implementation Complete - Ready for Sponsorship)

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

Did you try this on 8.6 or 9.x, if the error message is to be believed,
then swap is new to 9.x.

Eric

On Sat, Nov 8, 2025 at 7:03 AM Colin Macleod via Tcl-Core <
tcl...@li...> wrote:

> Similarly, if we restrict to numeric operands, an alternative to `land`
> would be `not; swap; not; bitor; not` .  However when I try this
> ::tcl::unsupported::assemble tells me `swap` is not a valid instruction,
> although it is listed in generic/tclAssembly.c  😮
>
> Colin.
> On 08/11/2025 08:45, Colin Macleod via Tcl-Core wrote:
>
> I haven't tested this, but a simpler alternative to `lor` could be `bitor;
> not; not` .
>
> Colin.
> On 08/11/2025 05:56, EricT wrote:
>
> HI all,
>
> Well it isn't pretty, but now we have an equivalent test for land/lor,
>
> Took a few go-arounds with gemini to get the logic right, but here's the
> replacements that work in both 8.6 and 9.x
>
>   foreach {op prec code} {
>     )  0 -
>     ,  0 -
>     =  0 -
>     ?  1 -
>     :  1 -
>     || 2 {jumpTrue true_res; jumpFalse pop_A; push 1; jump end_res; label
> pop_A; push 0; jump end_res; label true_res; pop; push 1; label end_res}
>     && 3 {jumpFalse pop_A; jumpFalse false_res; push 1; jump end_res;
> label pop_A; pop; label false_res; push 0; label end_res}
>     |  4 bitor
>     ^  5 bitxor
>     &  6 bitand
>     ......
>
>
> Not sure why they bothered to remove land/lor, couldn't have saved much by
> removing it. Now that's I guess what the developers will not like, that
> they can't just remove it if it goes public. But it was after all an easy
> fix. The other codes are unlikely to go away any time soon I would think.
> And a side by side compare shows that the only other differences, at least
> according to the list output by assemble if you give it an invalid one, are
> that these are all new to 9.x
>
> dictGetDef
>  dictPut
>  dictRemove
>  isEmpty
>  jumpTableNum
>  strge
>  strgt
>  strle
>  strlt
>  swap
>  tclooId
>
> Stack machines are kinda fun. And the assembler is actually pretty
> friendly, it knew in advance that I was going to have a stack imbalance,
> and then the next try gave a stack underrun, but it simply threw an error
> with a nice message. Very cool I'd say. They ain't kidding when they say, "
> Gemini can make mistakes, so double-check it ". Anyone care to verify
> these, though my 146 + 8 more for the logic test cases are all working on
> both 8.6 and  9.x.
>
> There is one thing, the code we're generating has to push all
> variable names, unlike expr where the compiler is smarter and has locals
> that it doesn't have to lookup by name each time. We can't use a peephole
> optimiser, like the compiler, so expr will always have that advantage. But
> we're in the same ballpark at least.
>
> Eric
>
>
> On Fri, Nov 7, 2025 at 5:44 PM Phillip Brooks <phi...@um...> wrote:
>
>> I would like to see something like this in the core.  Then, there is no
>> concern about using the undocumented interface.
>>
>> Phil
>>
>> On Fri, Nov 7, 2025 at 5:40 PM Steve Landers <st...@di...>
>> wrote:
>>
>>> I am very positive about Colin's approach, especially with the speedups
>>> you (Eric) have recommended.  In my opinion it offers the best hope of
>>> improving the expr command without breaking code or introducing Lots of
>>> Interminably Silly Parentheses (see what I did there?).
>>>
>>> As for bytecode changes,  as Phil notes they come with the risk of
>>> making the solution release-dependent but I don't think that should be seen
>>> as a show-stopper given the value of an improved expr.
>>>
>>> Just my 2c worth
>>>
>>> -- Steve
>>> On 8 Nov 2025 at 9:06 AM +0800, EricT <tw...@gm...>, wrote:
>>>
>>> Philip:
>>>
>>> Well, maybe it's a good thing that I don't have any tct votes. But now I
>>> have some pure tcl, that runs very fast and finally I can put the expr
>>> dragon to rest. I have several versions of tcl, and many of Ashok's great
>>> tclkit's bundled with twapi. I hope he finds a way to create more,
>>> especially for 9.x. I have some utilities that for some forgotten reason
>>> still need an older 8.6, and so that's how they launch.
>>>
>>> If you want to try my latest fork of Colin's masterpiece, you can just
>>> tclsh it and then take a look at the bytecode, as it dumps the cache at the
>>> end. There are now 140 test cases you can look through as examples of
>>> usage.  The last 10 also use : as the command name, which I think of as a
>>> slimmer alias of = that just seems to look right to my eyes. But = works as
>>> well.
>>>
>>> Here's the very latest:
>>>
>>> https://github.com/rocketship88/colin-parser
>>>
>>> Eric
>>>
>>>
>>> On Fri, Nov 7, 2025 at 4:16 PM Phillip Brooks <phi...@um...>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Fri, Nov 7, 2025 at 2:14 PM EricT <tw...@gm...> wrote:
>>>>
>>>>> Hi Phillip:
>>>>>
>>>>> In going from tcl 8.6 to tcl 9.0 the only things that broke, at least
>>>>> where Colin's program is concerned, were land and lor, which are no longer
>>>>> supported. If the bytecode were to have to support those two because they
>>>>> had been made public, I don't see the big harm. In 8.6 they'd already gone
>>>>> to a jump based arrangement for short circuiting. So, in 9.x they just
>>>>> removed these 2 instructions.
>>>>>
>>>>
>>>> The harm is that the bytecode is currently allowed to change completely
>>>> from release to release.   This allows for reorganization and optimization
>>>> that would otherwise be impossible.  The way you are using it is, I think,
>>>> safe since you only ever create and run it in the same session.  If opened
>>>> up for general use, people might try to save it to a file, and then use
>>>> that on a different release.   Others are more expert in this area than I
>>>> am, though.
>>>>
>>>> Phil
>>>>
>>>>> _______________________________________________
>>>> 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
>>>
>>> _______________________________________________
>> Tcl-Core mailing list
>> Tcl...@li...
>> https://lists.sourceforge.net/lists/listinfo/tcl-core
>>
>
>
> _______________________________________________
> Tcl-Core mailing lis...@li...://lists.sourceforge.net/lists/listinfo/tcl-core
>
>
>
> _______________________________________________
> Tcl-Core mailing lis...@li...://lists.sourceforge.net/lists/listinfo/tcl-core
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

Re: [TCLCORE] [Ext] Re: [=] for concise expressions (was Re: TIP 672 Implementation Complete - Ready for Sponsorship)

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

Similarly, if we restrict to numeric operands, an alternative to `land` 
would be `not; swap; not; bitor; not` .  However when I try this 
::tcl::unsupported::assemble tells me `swap` is not a valid instruction, 
although it is listed in generic/tclAssembly.c  😮

Colin.

On 08/11/2025 08:45, Colin Macleod via Tcl-Core wrote:
>
> I haven't tested this, but a simpler alternative to `lor` could be 
> `bitor; not; not` .
>
> Colin.
>
> On 08/11/2025 05:56, EricT wrote:
>> HI all,
>>
>> Well it isn't pretty, but now we have an equivalent test for land/lor,
>>
>> Took a few go-arounds with gemini to get the logic right, but here's 
>> the replacements that work in both 8.6 and 9.x
>>
>>   foreach {op prec code} {
>>     )  0 -
>>     ,  0 -
>>     =  0 -
>>     ?  1 -
>>     :  1 -
>>     || 2 {jumpTrue true_res; jumpFalse pop_A; push 1; jump end_res; 
>> label pop_A; push 0; jump end_res; label true_res; pop; push 1; label 
>> end_res}
>>     && 3 {jumpFalse pop_A; jumpFalse false_res; push 1; jump end_res; 
>> label pop_A; pop; label false_res; push 0; label end_res}
>>     |  4 bitor
>>     ^  5 bitxor
>>     &  6 bitand
>>     ......
>>
>>
>> Not sure why they bothered to remove land/lor, couldn't have saved 
>> much by removing it. Now that's I guess what the developers will not 
>> like, that they can't just remove it if it goes public. But it was 
>> after all an easy fix. The other codes are unlikely to go away any 
>> time soon I would think. And a side by side compare shows that the 
>> only other differences, at least according to the list output by 
>> assemble if you give it an invalid one, are that these are all new to 9.x
>>
>> dictGetDef
>>  dictPut
>>  dictRemove
>>  isEmpty
>>  jumpTableNum
>>  strge
>>  strgt
>>  strle
>>  strlt
>>  swap
>>  tclooId
>>
>> Stack machines are kinda fun. And the assembler is actually pretty 
>> friendly, it knew in advance that I was going to have a stack 
>> imbalance, and then the next try gave a stack underrun, but it simply 
>> threw an error with a nice message. Very cool I'd say. They ain't 
>> kidding when they say, " Gemini can make mistakes, so double-check it 
>> ". Anyone care to verify these, though my 146 + 8 more for the logic 
>> test cases are all working on both 8.6 and  9.x.
>>
>> There is one thing, the code we're generating has to push all 
>> variable names, unlike expr where the compiler is smarter and has 
>> locals that it doesn't have to lookup by name each time. We can't use 
>> a peephole optimiser, like the compiler, so expr will always have 
>> that advantage. But we're in the same ballpark at least.
>>
>> Eric
>>
>>
>> On Fri, Nov 7, 2025 at 5:44 PM Phillip Brooks <phi...@um...> wrote:
>>
>>     I would like to see something like this in the core.  Then, there
>>     is no concern about using the undocumented interface.
>>
>>     Phil
>>
>>     On Fri, Nov 7, 2025 at 5:40 PM Steve Landers
>>     <st...@di...> wrote:
>>
>>         I am very positive about Colin's approach, especially with
>>         the speedups you (Eric) have recommended.  In my opinion it
>>         offers the best hope of improving the expr command without
>>         breaking code or introducing Lots of Interminably Silly
>>         Parentheses (see what I did there?).
>>
>>         As for bytecode changes,  as Phil notes they come with the
>>         risk of making the solution release-dependent but I don't
>>         think that should be seen as a show-stopper given the value
>>         of an improved expr.
>>
>>         Just my 2c worth
>>
>>         -- Steve
>>         On 8 Nov 2025 at 9:06 AM +0800, EricT <tw...@gm...>, wrote:
>>>         Philip:
>>>
>>>         Well, maybe it's a good thing that I don't have any tct
>>>         votes. But now I have some pure tcl, that runs very fast and
>>>         finally I can put the expr dragon to rest. I have several
>>>         versions of tcl, and many of Ashok's great
>>>         tclkit's bundled with twapi. I hope he finds a way to create
>>>         more, especially for 9.x. I have some utilities that for
>>>         some forgotten reason still need an older 8.6, and so that's
>>>         how they launch.
>>>
>>>         If you want to try my latest fork of Colin's masterpiece,
>>>         you can just tclsh it and then take a look at the bytecode,
>>>         as it dumps the cache at the end. There are now 140 test
>>>         cases you can look through as examples of usage.  The last
>>>         10 also use : as the command name, which I think of as a
>>>         slimmer alias of = that just seems to look right to my eyes.
>>>         But = works as well.
>>>
>>>         Here's the very latest:
>>>
>>>         https://github.com/rocketship88/colin-parser
>>>
>>>         Eric
>>>
>>>
>>>         On Fri, Nov 7, 2025 at 4:16 PM Phillip Brooks
>>>         <phi...@um...> wrote:
>>>
>>>
>>>
>>>             On Fri, Nov 7, 2025 at 2:14 PM EricT <tw...@gm...>
>>>             wrote:
>>>
>>>                 Hi Phillip:
>>>
>>>                 In going from tcl 8.6 to tcl 9.0 the only things
>>>                 that broke, at least where Colin's program is
>>>                 concerned, were land and lor, which are no longer
>>>                 supported. If the bytecode were to have to support
>>>                 those two because they had been made public, I don't
>>>                 see the big harm. In 8.6 they'd already gone to a
>>>                 jump based arrangement for short circuiting. So, in
>>>                 9.x they just removed these 2 instructions.
>>>
>>>
>>>             The harm is that the bytecode is currently allowed to
>>>             change completely from release to release.   This allows
>>>             for reorganization and optimization that would otherwise
>>>             be impossible.  The way you are using it is, I think,
>>>             safe since you only ever create and run it in the same
>>>             session.  If opened up for general use, people might try
>>>             to save it to a file, and then use that on a different
>>>             release.   Others are more expert in this area than I
>>>             am, though.
>>>
>>>             Phil
>>>
>>>             _______________________________________________
>>>             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
>>
>>     _______________________________________________
>>     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
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] [Ext] Re: [=] for concise expressions (was Re: TIP 672 Implementation Complete - Ready for Sponsorship)

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

Hi Colin,

I know you didn't want to allow for any booleans, but I still am allowing
mine to use exactly "true" and "false" and with bitor

(this is 8.6)
 % tcl::unsupported::disassemble script {expr {1 | $a}}
  Command 1: "expr {1 | $a}"
    (0) push1 0 # "1"
    (2) push1 1 # "a"
    (4) loadStk
    (5) bitor
    (6) done

 % set a false
false
% expr {1 | $a}
can't use non-numeric string as operand of "|"

 % tcl::unsupported::disassemble script {expr {1 || $a}}
  Command 1: "expr {1 || $a}"
    (0) push1 0 # "1"
    (2) jumpTrue1 +11 # pc 13
    (4) push1 1 # "a"
    (6) loadStk
    (7) jumpTrue1 +6 # pc 13
    (9) push1 2 # "0"
    (11) jump1 +4 # pc 15
    (13) push1 0 # "1"
    (15) done
% expr {1 || $a}
1

So, even in 8.6 they're doing the short circuit with jumps. I guess the
jumpFalse and jumpTrue are more tcl like. But this operator as a true/false
test is probably not used that much in calculations, so likely not a
big deal, but at least it doesn't throw an error anymore.

Thanks,

Eric


On Sat, Nov 8, 2025 at 12:45 AM Colin Macleod via Tcl-Core <
tcl...@li...> wrote:

> I haven't tested this, but a simpler alternative to `lor` could be `bitor;
> not; not` .
>
> Colin.
> On 08/11/2025 05:56, EricT wrote:
>
> HI all,
>
> Well it isn't pretty, but now we have an equivalent test for land/lor,
>
> Took a few go-arounds with gemini to get the logic right, but here's the
> replacements that work in both 8.6 and 9.x
>
>   foreach {op prec code} {
>     )  0 -
>     ,  0 -
>     =  0 -
>     ?  1 -
>     :  1 -
>     || 2 {jumpTrue true_res; jumpFalse pop_A; push 1; jump end_res; label
> pop_A; push 0; jump end_res; label true_res; pop; push 1; label end_res}
>     && 3 {jumpFalse pop_A; jumpFalse false_res; push 1; jump end_res;
> label pop_A; pop; label false_res; push 0; label end_res}
>     |  4 bitor
>     ^  5 bitxor
>     &  6 bitand
>     ......
>
>
> Not sure why they bothered to remove land/lor, couldn't have saved much by
> removing it. Now that's I guess what the developers will not like, that
> they can't just remove it if it goes public. But it was after all an easy
> fix. The other codes are unlikely to go away any time soon I would think.
> And a side by side compare shows that the only other differences, at least
> according to the list output by assemble if you give it an invalid one, are
> that these are all new to 9.x
>
> dictGetDef
>  dictPut
>  dictRemove
>  isEmpty
>  jumpTableNum
>  strge
>  strgt
>  strle
>  strlt
>  swap
>  tclooId
>
> Stack machines are kinda fun. And the assembler is actually pretty
> friendly, it knew in advance that I was going to have a stack imbalance,
> and then the next try gave a stack underrun, but it simply threw an error
> with a nice message. Very cool I'd say. They ain't kidding when they say, "
> Gemini can make mistakes, so double-check it ". Anyone care to verify
> these, though my 146 + 8 more for the logic test cases are all working on
> both 8.6 and  9.x.
>
> There is one thing, the code we're generating has to push all
> variable names, unlike expr where the compiler is smarter and has locals
> that it doesn't have to lookup by name each time. We can't use a peephole
> optimiser, like the compiler, so expr will always have that advantage. But
> we're in the same ballpark at least.
>
> Eric
>
>
> On Fri, Nov 7, 2025 at 5:44 PM Phillip Brooks <phi...@um...> wrote:
>
>> I would like to see something like this in the core.  Then, there is no
>> concern about using the undocumented interface.
>>
>> Phil
>>
>> On Fri, Nov 7, 2025 at 5:40 PM Steve Landers <st...@di...>
>> wrote:
>>
>>> I am very positive about Colin's approach, especially with the speedups
>>> you (Eric) have recommended.  In my opinion it offers the best hope of
>>> improving the expr command without breaking code or introducing Lots of
>>> Interminably Silly Parentheses (see what I did there?).
>>>
>>> As for bytecode changes,  as Phil notes they come with the risk of
>>> making the solution release-dependent but I don't think that should be seen
>>> as a show-stopper given the value of an improved expr.
>>>
>>> Just my 2c worth
>>>
>>> -- Steve
>>> On 8 Nov 2025 at 9:06 AM +0800, EricT <tw...@gm...>, wrote:
>>>
>>> Philip:
>>>
>>> Well, maybe it's a good thing that I don't have any tct votes. But now I
>>> have some pure tcl, that runs very fast and finally I can put the expr
>>> dragon to rest. I have several versions of tcl, and many of Ashok's great
>>> tclkit's bundled with twapi. I hope he finds a way to create more,
>>> especially for 9.x. I have some utilities that for some forgotten reason
>>> still need an older 8.6, and so that's how they launch.
>>>
>>> If you want to try my latest fork of Colin's masterpiece, you can just
>>> tclsh it and then take a look at the bytecode, as it dumps the cache at the
>>> end. There are now 140 test cases you can look through as examples of
>>> usage.  The last 10 also use : as the command name, which I think of as a
>>> slimmer alias of = that just seems to look right to my eyes. But = works as
>>> well.
>>>
>>> Here's the very latest:
>>>
>>> https://github.com/rocketship88/colin-parser
>>>
>>> Eric
>>>
>>>
>>> On Fri, Nov 7, 2025 at 4:16 PM Phillip Brooks <phi...@um...>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Fri, Nov 7, 2025 at 2:14 PM EricT <tw...@gm...> wrote:
>>>>
>>>>> Hi Phillip:
>>>>>
>>>>> In going from tcl 8.6 to tcl 9.0 the only things that broke, at least
>>>>> where Colin's program is concerned, were land and lor, which are no longer
>>>>> supported. If the bytecode were to have to support those two because they
>>>>> had been made public, I don't see the big harm. In 8.6 they'd already gone
>>>>> to a jump based arrangement for short circuiting. So, in 9.x they just
>>>>> removed these 2 instructions.
>>>>>
>>>>
>>>> The harm is that the bytecode is currently allowed to change completely
>>>> from release to release.   This allows for reorganization and optimization
>>>> that would otherwise be impossible.  The way you are using it is, I think,
>>>> safe since you only ever create and run it in the same session.  If opened
>>>> up for general use, people might try to save it to a file, and then use
>>>> that on a different release.   Others are more expert in this area than I
>>>> am, though.
>>>>
>>>> Phil
>>>>
>>>>> _______________________________________________
>>>> 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
>>>
>>> _______________________________________________
>> Tcl-Core mailing list
>> Tcl...@li...
>> https://lists.sourceforge.net/lists/listinfo/tcl-core
>>
>
>
> _______________________________________________
> Tcl-Core mailing lis...@li...://lists.sourceforge.net/lists/listinfo/tcl-core
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

Re: [TCLCORE] [Ext] Re: [=] for concise expressions (was Re: TIP 672 Implementation Complete - Ready for Sponsorship)

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

I haven't tested this, but a simpler alternative to `lor` could be 
`bitor; not; not` .

Colin.

On 08/11/2025 05:56, EricT wrote:
> HI all,
>
> Well it isn't pretty, but now we have an equivalent test for land/lor,
>
> Took a few go-arounds with gemini to get the logic right, but here's 
> the replacements that work in both 8.6 and 9.x
>
>   foreach {op prec code} {
>     )  0 -
>     ,  0 -
>     =  0 -
>     ?  1 -
>     :  1 -
>     || 2 {jumpTrue true_res; jumpFalse pop_A; push 1; jump end_res; 
> label pop_A; push 0; jump end_res; label true_res; pop; push 1; label 
> end_res}
>     && 3 {jumpFalse pop_A; jumpFalse false_res; push 1; jump end_res; 
> label pop_A; pop; label false_res; push 0; label end_res}
>     |  4 bitor
>     ^  5 bitxor
>     &  6 bitand
>     ......
>
>
> Not sure why they bothered to remove land/lor, couldn't have saved 
> much by removing it. Now that's I guess what the developers will not 
> like, that they can't just remove it if it goes public. But it was 
> after all an easy fix. The other codes are unlikely to go away any 
> time soon I would think. And a side by side compare shows that the 
> only other differences, at least according to the list output by 
> assemble if you give it an invalid one, are that these are all new to 9.x
>
> dictGetDef
>  dictPut
>  dictRemove
>  isEmpty
>  jumpTableNum
>  strge
>  strgt
>  strle
>  strlt
>  swap
>  tclooId
>
> Stack machines are kinda fun. And the assembler is actually pretty 
> friendly, it knew in advance that I was going to have a stack 
> imbalance, and then the next try gave a stack underrun, but it simply 
> threw an error with a nice message. Very cool I'd say. They ain't 
> kidding when they say, " Gemini can make mistakes, so double-check it 
> ". Anyone care to verify these, though my 146 + 8 more for the logic 
> test cases are all working on both 8.6 and  9.x.
>
> There is one thing, the code we're generating has to push all 
> variable names, unlike expr where the compiler is smarter and has 
> locals that it doesn't have to lookup by name each time. We can't use 
> a peephole optimiser, like the compiler, so expr will always have that 
> advantage. But we're in the same ballpark at least.
>
> Eric
>
>
> On Fri, Nov 7, 2025 at 5:44 PM Phillip Brooks <phi...@um...> wrote:
>
>     I would like to see something like this in the core.  Then, there
>     is no concern about using the undocumented interface.
>
>     Phil
>
>     On Fri, Nov 7, 2025 at 5:40 PM Steve Landers
>     <st...@di...> wrote:
>
>         I am very positive about Colin's approach, especially with the
>         speedups you (Eric) have recommended.  In my opinion it offers
>         the best hope of improving the expr command without breaking
>         code or introducing Lots of Interminably Silly Parentheses
>         (see what I did there?).
>
>         As for bytecode changes,  as Phil notes they come with the
>         risk of making the solution release-dependent but I don't
>         think that should be seen as a show-stopper given the value of
>         an improved expr.
>
>         Just my 2c worth
>
>         -- Steve
>         On 8 Nov 2025 at 9:06 AM +0800, EricT <tw...@gm...>, wrote:
>>         Philip:
>>
>>         Well, maybe it's a good thing that I don't have any tct
>>         votes. But now I have some pure tcl, that runs very fast and
>>         finally I can put the expr dragon to rest. I have several
>>         versions of tcl, and many of Ashok's great
>>         tclkit's bundled with twapi. I hope he finds a way to create
>>         more, especially for 9.x. I have some utilities that for some
>>         forgotten reason still need an older 8.6, and so that's how
>>         they launch.
>>
>>         If you want to try my latest fork of Colin's masterpiece, you
>>         can just tclsh it and then take a look at the bytecode, as it
>>         dumps the cache at the end. There are now 140 test cases you
>>         can look through as examples of usage.  The last 10 also use
>>         : as the command name, which I think of as a slimmer alias of
>>         = that just seems to look right to my eyes. But = works as well.
>>
>>         Here's the very latest:
>>
>>         https://github.com/rocketship88/colin-parser
>>
>>         Eric
>>
>>
>>         On Fri, Nov 7, 2025 at 4:16 PM Phillip Brooks
>>         <phi...@um...> wrote:
>>
>>
>>
>>             On Fri, Nov 7, 2025 at 2:14 PM EricT <tw...@gm...>
>>             wrote:
>>
>>                 Hi Phillip:
>>
>>                 In going from tcl 8.6 to tcl 9.0 the only things that
>>                 broke, at least where Colin's program is concerned,
>>                 were land and lor, which are no longer supported. If
>>                 the bytecode were to have to support those two
>>                 because they had been made public, I don't see the
>>                 big harm. In 8.6 they'd already gone to a jump based
>>                 arrangement for short circuiting. So, in 9.x they
>>                 just removed these 2 instructions.
>>
>>
>>             The harm is that the bytecode is currently allowed to
>>             change completely from release to release. This allows
>>             for reorganization and optimization that would otherwise
>>             be impossible.  The way you are using it is, I think,
>>             safe since you only ever create and run it in the same
>>             session. If opened up for general use, people might try
>>             to save it to a file, and then use that on a different
>>             release. Others are more expert in this area than I am,
>>             though.
>>
>>             Phil
>>
>>             _______________________________________________
>>             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
>
>     _______________________________________________
>     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