Menu
▾
▴
Re: [TCLCORE] [Ext] Prototype Implementation of TIP 672 - $(expr) Syntax
|
From: Florent M. <flo...@gm...> - 2025-10-21 19:04:39
|
Yes you are right, I was wrong, {*} is not implemented into Tcl_ParseToken.
There is no need for it.
But it can't be the same for an {=} prefix : it should be detected
inside tokens.
Florent
Le 21/10/2025 à 20:54, EricT a écrit :
> I don't think you are correct about {*} in a bareword that's not in
> quotes:
>
> % proc foo args {puts /$args/}
> % foo something{*}{1 + 2 + 3}suffix
> /something\{*\}\{1 + 2 + 3\}suffix/
> % foo something{*}{1+2+3}suffix
> /something{*}{1+2+3}suffix/
> % foo {*}{1 2 3}
> /1 2 3/
> % foo {*}"1 2 3"
> /1 2 3/
> % foo {*}"123"
> /123/
> In either of the first 2 cases, it is inserting the {*}{...} as simply
> text, it is not removing the {*} nor the enclosing {...} and then
> expanding it to a list. However, it does do all those steps in the 3rd
> - 5th cases because {*} begins the word.
>
> Eric
>
>
> On Tue, Oct 21, 2025 at 11:37 AM EricT <tw...@gm...> wrote:
>
> Ok, so from what I can tell, you are saying that your {=} will not
> substitute if inside of "quotes {=}..." or barewords.
>
> Here's $(expr) today:
>
> (bin) 1 % set foo "abc $(1 + 2 + 3) def"
> abc 6 def
> (bin) 2 % set foo something$(1 + 2 + 3)
> something6
> (bin) 3 % string range "abcdef" 1 end-$(3-2)
> bcde
> (bin) 4 % set n 3
> 3
> (bin) 5 % string range "abcdef" 1 end-$($n-2)
> bcde
>
> Can your proposed {=} do this, because [expr] can do it too. And
> therefore so can $(expr).
>
> Eric
>
>
> On Tue, Oct 21, 2025 at 11:24 AM Florent Merlet
> <flo...@gm...> wrote:
>
> Le 21/10/2025 à 19:16, EricT a écrit :
>> The code that handles {*} is somewhat simple because it
>> begins at a word boundary only:
>>
>> % set foo "abc {*}{1 +2 +3}"
>> abc {*}{1 +2 +3}
>> % set foo something{*}{1 + 2 + 3}suffix
>> wrong # args: should be "set varName ?newValue?"
>>
>> That means that if his {=} code is implemented the same as
>> {*} the above is what you will get.
>
> Your coding experiment shows precisely that {*} doesn't work
> only at a word boundary.
>
> if {*} were not detected, « set » would not have complained :
> it would have silently set foo as "something{*}{1 + 2 + 3}suffix"
>
> But, as {*} has been detected, it then evaluates something like :
>
> % set foo something1 2 3suffix # (? to be checked ?)
>
> This gives at least 4 arguments to « set », so you got this error.
>
> That means that if his {=} code is implemented the same as
> {*}, the interpreter would have computed the expression 1+2+3
> and returned the number 6, so that the variable foo would have
> been set to « something6suffix ».
>
> {*} is ignored only between quotes. This is'nt an error :
>
> % set foo "something{*}{1 + 2 + 3}suffix"
>
> -> something{*}{1 + 2 + 3}suffix
>
>>
>> On the other hand, $(expr) works everywhere $var works. That
>> is why it can be implemented in ~100 lines of code.
>>
>> But again, I may be wrong, I was hoping to hear from Florent
>> on this.
>>
>> Eric
>>
>>
>> On Tue, Oct 21, 2025 at 6:00 AM Zaumseil René via Tcl-Core
>> <tcl...@li...> wrote:
>>
>> Hello Eric
>>
>> A solution to the second point is also in the mail from
>> Florent Merlot with extending {=}
>>
>> The third point is about a radical change with removing
>> the $-sign to access variables, p.e. x=y+a. This is way
>> out of current proposals.
>>
>> Regards
>>
>> rene
>>
>> *Von:*EricT <tw...@gm...>
>> *Gesendet:* Dienstag, 21. Oktober 2025 14:53
>> *An:* Zaumseil René <RZa...@kk...>
>> *Cc:* tc...@ro...; tcl...@li...;
>> et...@ro...
>> *Betreff:* Re: [TCLCORE] [Ext] Prototype Implementation
>> of TIP 672 - $(expr) Syntax
>>
>> The main reason for the $(...) syntax is to encourage the
>> use of safer, compiled, expression code. Since it would
>> also be easier to read and write, users would gravitate
>> to its use and automatically get the benefit of braced
>> expr code.
>>
>> The secondary reason is that many have complained about
>> [expr {}] being, not as clean syntax as they would like
>> for expression handling. So, like $var instead of [set
>> var] a $(...) shorthand for [expr {...}].
>>
>> I looked at TIP 647, is that the one you really meant, I
>> saw only a discussion on Tk_ConfigureWidgets().
>>
>> Can you elaborate on your 3rd point? I don't quite
>> understand.
>>
>> Eric
>>
>> On Tue, Oct 21, 2025 at 1:36 AM Zaumseil René via
>> Tcl-Core <tcl...@li...> wrote:
>>
>> Hello
>>
>> I currently do not see the benefit of this proposal,
>> except some char less to type.
>>
>> IMHO expr has some problems or room for enhancements:
>>
>> 1. Double evaluation of arguments
>>
>> Could be solved with a new command with only 1 argument
>>
>> 2. Returns only one value
>>
>> See p.e. tip 647 syntax
>>
>> 3. Access to tcl-variables with $-syntax
>>
>> This would require a new expression parser
>>
>> 4. Anything else?
>>
>> Do the tip 672 solve one of these points?
>>
>> Regards
>>
>> rene
>>
>> *Von:*EricT <tw...@gm...>
>> *Gesendet:* Freitag, 17. Oktober 2025 23:22
>> *An:* tcl...@li...
>> *Cc:* et...@ro...
>> *Betreff:* [Ext] [TCLCORE] Prototype Implementation
>> of TIP 672 - $(expr) Syntax
>>
>> Hello Tcl Core Team,
>>
>> I have developed a working prototype implementation
>> of TIP 672, which adds the $(expression) syntax as a
>> more intuitive alternative to [expr {expression}].
>>
>> Repository:
>> https://github.com/rocketship88/tcl-tip-672-prototype
>>
>> The implementation is minimal, modifying only two
>> files (tclParse.c and tclNamesp.c) with approximately
>> 100 lines of changes. The key modification converts
>> the existing two-way branch in Tcl_ParseVarName to a
>> three-way branch, with the new path handling $(...)
>> by creating a synthetic [expr {...}] command string.
>>
>> Key Accomplishments:
>>
>> Full bytecode compilation: The synthetic string
>> approach integrates seamlessly with the existing
>> compiler, producing identical optimized bytecode as
>> [expr {...}]. The disassembler output (shown in the
>> README) demonstrates efficient variable loading with
>> no runtime parsing overhead.
>>
>> Proven approach: Jim Tcl has used this syntax
>> successfully for years
>>
>> Comprehensive testing: Works correctly with string
>> interpolation, variable scoping, error handling, and
>> interactive mode
>>
>> Known Limitations:
>>
>> Memory leak: The synthetic string is allocated but
>> not tracked for cleanup in Tcl_FreeParse. This
>> requires core team guidance on the preferred solution
>> (modify Tcl_Parse structure vs. thread-local tracking).
>>
>> Error messages: Currently show the synthetic command
>> rather than the original $(...) syntax, though this
>> is arguably helpful for debugging.
>>
>> Questions for the Team:
>>
>> What is the preferred approach for tracking synthetic
>> strings for cleanup?
>> Is this prototype architecture acceptable for Tcl 9.x?
>> Are there concerns with the synthetic string approach
>> that I should address?
>>
>> The complete implementation with side-by-side diffs
>> is available in the repository. I'm happy to refine
>> the code based on your feedback and would appreciate
>> any guidance on moving this forward.
>>
>> Best regards,
>> Eric
>>
>> _______________________________________________
>> 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
> --
> ------------------------------------------------------------------------
> *Florent MERLET*
> /4 rue Johann Strauss
> Logement 7
> 86180 BUXEROLLES/
> ------------------------------------------------------------------------
> *Mél.* : /flo...@gm.../
> *Tél.* : /06 70 00 63 48/
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>
--
------------------------------------------------------------------------
*Florent MERLET*
/4 rue Johann Strauss
Logement 7
86180 BUXEROLLES/
------------------------------------------------------------------------
*Mél.* : /flo...@gm.../
*Tél.* : /06 70 00 63 48/
|
