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

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

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
>