Menu
▾
▴
Re: [TCLCORE] [Ext] Re: [=] for concise expressions (was Re: TIP 672 Implementation Complete - Ready for Sponsorship)
|
From: EricT <tw...@gm...> - 2025-11-09 07:04:29
|
Hi Don:
I understand your concern. But if history is any guide, it's far easier to
get tcl to stay the same than to change. I doubt there will be any
incompatibilities with the use of the assemble command, at least not in my
lifetime. And if I were to live to see it, I expect I'll just ask my robot
to fix the code. The one I use now is a very good C and Tcl programmer. And
as Perry White said to Lois Lane when he hired Clark Kent: In my 40 years
in this business, he's the fastest typist I've ever seen.
So, I've put the final touches on the Colin fork, putting everything except
one global into a Calc:: namespace. It works just fine now in 8.6 and 9.x.
and so I'll leave this debate to others. I want to thank everyone for their
comments. It has been quite an interesting month.
Eric
On Sat, Nov 8, 2025 at 3:02 PM Donald Porter via Tcl-Core <
tcl...@li...> wrote:
> 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...> 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
>>
> _______________________________________________
> 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
>
|
