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