Menu
▾
▴
Re: [TCLCORE] TIP 676 C implementation
|
From: Colin M. <col...@ya...> - 2025-12-06 16:25:41
|
Yet another bugfix. The code to fallback to non-compiled if the
preconditions for the compiled code were not met was using `=` literally
as the command name. This fails if `=` has been renamed (as it might be
by someone who has a pre-existing `=` command):
% rename = eqs
% eqs 3+5
8
% eqs 3 + [pwd]
= Expected start of expression but found '/'
% proc tt {} {eqs 3 + [pwd]}
% tt
invalid command name "="
This is now fixed, with the patch file updated again:
https://cmacleod.me.uk/tcl/tip676.patch.txt.
Colin.
On 06/12/2025 13:58, Colin Macleod via Tcl-Core wrote:
>
> Hello all, I would like to ask for feedback on another little wrinkle
> I have just noticed.
>
> In the TIP and the manual page I say that it is an error for variables
> used in an expression with `=` to be non-numeric. I don't actually
> have any code to enforce this. I was just relying on the numeric
> operators giving an error for non-numeric arguments.
>
> Only now I remembered that many of them do accept string arguments, so
> with the current code one can do things like:
>
> % set a foo; set b bar
> bar
> % = a
> foo
> % = a==b
> 0
> % = a<b?a:b
> bar
> % set t true
> true
> % = !t
> 0
> % = a+1
> cannot use non-numeric string "foo" as left operand of "+"
>
> To resolve this I could either do:
>
> 1. Add checks to the generated code to give an error if any variable
> turns out to have a non-numeric value.
> 2. Leave the current behaviour alone and update the documentation to
> reflect this.
>
> I'm more inclined to go with option 2 - runtime checks will complicate
> and slow down the generated bytecode, and I doubt that the current
> behaviour will cause problems. What do other people think?
>
> Colin.
>
>
> On 04/12/2025 14:47, Colin Macleod via Tcl-Core wrote:
>>
>> Hello once again,
>>
>> I have now updated the Implementation section of TIP 676. I also
>> made a minor tweak to the code to more clearly differentiate variable
>> names and numbers.
>>
>> I think my work on this is now finished, at least until I get some
>> feedback from others. I am hoping it can be included in 9.1a1.
>>
>> Colin.
>>
>> On 03/12/2025 15:49, Colin Macleod via Tcl-Core wrote:
>>>
>>> Hi again,
>>>
>>> I decided to treat "NaN", "Inf" & "Infinity" (any capitalisation) as
>>> variable names, eliminating that special case. Does anyone actually
>>> write expressions, other than test cases, using these values? If so
>>> they will need to stick to `expr`. I have updated the code, tests
>>> and man page to reflect this, and updated the patch at
>>> https://cmacleod.me.uk/tcl/tip676.patch.txt.
>>>
>>> I have also added an equals.test file of tests. Some of these I
>>> have adapted from the existing tests for `expr`, but more than half
>>> were contributed by Eric, which is extremely helpful.
>>>
>>> I now need to update the TIP to match the implementation. Once that
>>> is done I think it will be ready for formal consideration.
>>>
>>> Colin.
>>>
>>> On 02/12/2025 17:10, Colin Macleod wrote:
>>>>
>>>> Hi again all,
>>>>
>>>> I'm now working on creating tests for the `=` command, by adapting
>>>> the tests for `expr` which are relevant. This has highlighted a
>>>> few edge cases which I'm not sure how best to handle, so I would
>>>> like to ask what other people think.
>>>>
>>>> When given a single number as the expression, `expr` always
>>>> rewrites it to decimal form. At present `=` leaves it unchanged
>>>> unless it's used in a calculation:
>>>>
>>>> % expr 0xff
>>>> 255
>>>> % = 0xff
>>>> 0xff
>>>> % = 0xff + 0
>>>> 255
>>>>
>>>> So in this case `=` behaves differently from `expr` - I don't think
>>>> this is really a problem and I would rather not introduce an
>>>> unnecessary conversion here. Is this acceptable?
>>>>
>>>> I'm not allowing the non-numeric representations of boolean values:
>>>> true, false, yes, no, etc. The `expr` code also accepts any
>>>> abbreviations of these, doing this in `=` would make it impossible
>>>> to use variables called t, f, y or n, which I think is
>>>> unacceptable. However the current `=` does accept Inf and NaN
>>>> (with any capitalisation, but not abbreviated) as numeric
>>>> constants, which makes it impossible to use variables with those
>>>> names. I'm not very happy about this being a special case, so I'm
>>>> wondering about disallowing those also. If so, someone who really
>>>> wanted to use such a value in a computation could still do so by
>>>> assigning it to a variable first and using that variable in the `=`
>>>> command: *set nan NaN; = nan + 0 *. What do others think?
>>>>
>>>> Combining these two issues, we get the following:
>>>>
>>>> % expr nan
>>>> domain error: argument not in valid range
>>>> % = nan
>>>> nan
>>>> % = nan + 0
>>>> cannot use non-numeric floating-point value "nan" as left
>>>> operand of "+"
>>>>
>>>> Acceptable or not?
>>>>
>>>> If anyone would like to experiment, I think the code at
>>>> https://cmacleod.me.uk/tcl/tip676.patch.txt is now fairly solid.
>>>> It would be good to get feedback, not just on these specific issues
>>>> but on the whole approach.
>>>>
>>>> Best regards,
>>>> Colin.
>>>>
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core |
