Menu
▾
▴
Re: [TCLCORE] [Ext] Re: [=] for concise expressions (was Re: TIP 672 Implementation Complete - Ready for Sponsorship)
|
From: EricT <tw...@gm...> - 2025-11-08 22:50:47
|
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
>
|
