Re: [TCLCORE] TIP 676 C implementation

[Colin M. <col...@ya...>]

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.
>>>