|
From: EricT <tw...@gm...> - 2025-10-25 16:47:04
|
Hi Jan,
Regarding "Expression Substitution - Size Difference Mechanism and New
Opportunities":
Thank you for the clarification about TIP 465 and your endorsement of the
$((expr)) syntax! Your refactoring work has actually opened up some
interesting opportunities I wanted to share.
Background on the Size Difference Approach:
In the original implementation, we used a constant size difference
(EXPR_SIZE_DIFF) between the original syntax (e.g., $((expr))) and the
synthetic string ([expr {expr}]). This was necessary because when
TclParseExprSubst creates the synthetic string and stores it in the token,
the token's size reflects the synthetic string length. However, ParseTokens
needs to advance its src and numBytes by the *original* syntax length. By
maintaining a fixed offset between the two representations, we could
calculate the original size as syntheticSize - EXPR_SIZE_DIFF.
New Opportunity from Your Refactoring:
With TclParseExprSubst now being a private function called only from within
ParseTokens, we have the freedom to modify its calling sequence! We could
have it return the actual original size consumed (via an output parameter
or other mechanism), eliminating the need for the constant offset
calculation entirely. This would make the code cleaner and more robust.
Regarding the email I sent you earlier about the issue with missing closing
parentheses - that concern wouldn't be in play with this new approach.
Since we can return to the caller the actual size of the expression (which
we know through the balancing of the ()'s), we can also handle cases where
users accidentally (or purposely) leave off the second trailing ) without
causing negative numBytes values.
What do you think about this?
Best regards,
Eric
On Sat, Oct 25, 2025 at 2:07 AM Jan Nijtmans <jan...@gm...> wrote:
> Op za 25 okt 2025 om 01:34 schreef Phillip Brooks:
> > tags: trunk, main
> >
> > comment: TIP #465: Change Rule 8 of the Dodekalogue to Cut Some
> Corner Cases (user: jan.nijtmans)
> >
> >
> > Jan, Can you confirm whether the current behavior here is correct for
> 9.0 - or is it a bug? If it is correct behavior, then it seems that the
> $(( expression )) syntax is currently guarded from being recognized as
> valid syntax at least in this context.
> >
> >
> > If it is a bug, can you explain the intent of the change?
>
> Everything you want to know about it (hopefully) can be found
> here:
> <https://core.tcl-lang.org/tips/doc/trunk/tip/465.md>
>
> It - indeed - means that the $(( ... )) syntax is invalid in Tcl 9.0,
> so it can safely be used for "expression substitution".
>
> I think we should go for this syntax!
> Jan Nijtmans
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>
|