Tcl Source Code

Example:

$ tclsh9.0
% set x [lseq 1 11111111111111];set y 5
5
% expr {$x+$y}

Doing this hangs a long time, because a string representation is generated for the lseq. But we know already that an lseq with 0 or >1 entry can never be handled by '+'. Would be nice to detect that early, without taking that much time.

Should be [a618dcb27007fabd|better] now. Also (partly) backported to 8.7

> Calling something "a list" because TMLL() returns a value bigger than 1 is not an accurate claim.

Indeed! There's still time until 9.0.1 to make it better. Current use was meant as a quick fix, in order to - at least - prevent conversion to a list.

Beware that TclMaxListLength() is not written to be accurate.
It is written to be reasonably quick, and to produce an over-estimate
of how many elements the list might have -- if it is a list at all.

Calling something "a list" because TMLL() returns a value bigger than 1
is not an accurate claim.

More examples handled now (integers and doubles):

$ tclsh9.0
%  set x [lseq 1 11111111111111]
5
% binary encode base64 -maxlen $x data
expected integer but got a list
% binary format d $x
expected floating-point number but got a list

See: [5d333307578b6a00]

While testing:

$ tclsh9.0
% set x [lseq 1 11111111111111];set y 5
5
% if {$x} {puts stdout abc}

This also hangs, and could be handled the same way.

Christian Werner wrote:

While I fully support elimination of single single quotes in error
messages regardless of formalism or conversation I wonder how many
omelettes we'll be able to make from the potentially many broken eggs.
Alternatively, we could conserve these eggs for later.

Best,
Christian

Remark by Brian Griffin:

The only change I would recommend is to not use a contraction in the error message. In other words, use “cannot” instead of “can’t”. IMO, messages should be formal, not conversational.

-Brian

I think [2290847d23a494e4|this] is how it should be:

If the obj being handled by "expr" can be represented as a list and has more than 1 element (so a dict as well), it now gives a slightly different error-message:

% set x [lseq 1 11111111111111];set y 5
5
% expr {$x+$y}
can't use a list as operand of "+"

A side-effect of this is that Tcl_GetNumberFromObj() now tries to convert the object to a list, if it isn't already one of the other known types (like dict, lseq, or index). That's very useful in further error-handling, since the typePtr or lengthProc then can be inspected for this case without trying to do more parsing.

It might also be very useful for the implementation of a future Tcl_GetValueFromObj() ....

I think [2290847d23a494e4|this] is how it should be:

If the obj being handled by "expr" can be represented as a list and has more than 1 element (so a dict as well), it now gives a slightly different error-message:

<pre>
% set x [lseq 1 11111111111111];set y 5
5
% expr {$x+$y}
can't use a list as operand of "+"
</pre>

A side-effect of this is that Tcl_GetNumberFromObj() now tries to
convert the object to a list, if it isn't already one of the
other known types (like dict, lseq, or index). That's very useful in
further error-handling, since the typePtr or lengthProc then
can be inspected for this case without trying to do more parsing.

It might also be very useful for the implementation of a future
Tcl_GetValueFromObj() ....