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 15:03:33
|
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 |
