Menu
▾
▴
Re: [TCLCORE] [Ext] Re: [=] for concise expressions (was Re: TIP 672 Implementation Complete - Ready for Sponsorship)
|
From: Colin M. <col...@ya...> - 2025-11-08 08:45:30
|
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 |
