Tcl Source Code

The following interactive session illustrates that two logically equivalent sequences do not have the same string representation:

% lseq 3
0 1 2
% lseq 3.0
0.0 1.0 2.0
% string compare [lseq 3] [lseq 3.0]
-1

Overloading the count argument in this way is probably opening a can of worms.

Brian said that lseq arguments are expressions on its own. This makes the difference, as it is fed to expr.

Thanks, Harald

I would be in favor to make this compatible.
Entier (bignum) and float is really different internally and "entier float" is hard to fullfill in many cases.

Harald

% string repeat x 2.0
expected integer but got "2.0"
% lrepeat 2.0 x
expected integer but got "2.0"
% # BUT
% lseq 2.0
0.0 1.0

The numeric type (Integer vs Real) of the Count parameter should not be used to determine the formatting of the results. A Real value can be given as the Count value, but only if the value is a whole number.
These changes have been implemented in [93057ed877].

As for the other suggestions and critiques, I am very reluctant to change the command argument syntax since this command is already in active use. If the above change impacts any existing applications, it's probably for the better.

Following sebres' line of thinking, an alternative would be to eliminate "count" as an argument entirely. "from", "to", and "by" are probably sufficient.

When behaviour follows meaning, it is intuitive. 3.0 and 3 have the same meaning:

% expr {3.0 == 3}
1

Therefore, prohibiting 3.0 as the value of the count argument would be less intuitive and more awkward. Artificial constraints like that have generally been avoided for Tcl.

This particular report is only about the "count" argument. At least for that option 3 and 3.0 both mean the same thing. Having "count" always be interpreted as a whole number still leaves plenty of room to influence the behaviour of [lseq] using the other arguments that it accepts.

Dear Sergey,

thank you for your insights.

The explanation, that:

lseq 3.0

lseq 0 to 3.0

So, I tried the equivalence:

% lseq 0 to 3.0
0.0 1.0 2.0 3.0
% lseq 3.0
0.0 1.0 2.0
% lseq 0 to 3.5
0.0 1.0 2.0 3.0

For me, the item "3.0" is missing in the "lseq 3.0" case.

Thank you all for all, Harald

It looks completely fine and desirable to me... Also code says it (I know that exactly, because I touched it as I fixed lseq in [f05f5ef759] and it was pretty obvious intentional).

I see it simply as an equivalent of lseq ?0 to? 3.0 (further below).

>two logically equivalent sequences do not have the same string representation

Nothing is here equivalent. Why don't you not wonder that following are different?

% string compare [expr 3] [expr 3.0]
-1
% string compare [expr int(3)] [expr double(3)]
-1

Most interesting is the question what would happen if the object gets shimmer internally to double. And this can be answered as it'd behave correct. Just because an entier would never shimmer to floating type (because its string representation wouldn't concur for both type). With other words because Tcl_GetDoubleFromObj and co would obtain double from integer without to shimmer:

% list [set i [expr 3]] [tcl::unsupported::representation $i]
3 {value is a int ...}
% lseq $i
0 1 2
% list [expr {double($i)}] [tcl::unsupported::representation $i]
3.0 {value is a int ...}
% lseq $i
0 1 2

So shimmering issue is excluded. Nothing else matters.

Moreover lseq natively supports expressions, so lseq 3.0 is quasi equivalent to lseq [expr {3.0}] and this is also possible (and deliberate):

% lseq double(3)
0.0 1.0 2.0

> Specially here is clear that the count is an entier:
> % lseq 3.5
> expected integer but got "3.5"

It is not clear to me. IMHO, it is simply undefined currently, but easy too fix: To be consistent, I'd rather prefer to change the command so this:

% lseq 3.0
0.0 1.0 2.0
% lseq 3.5
0.0 1.0 2.0 3.0
# with other words it'd become short equivalent to:
% lseq 0 to 3.5
0.0 1.0 2.0 3.0

- lseq start ?(..|to)? end ??by? step?
+ lseq ?start ?(..|to)?? end ??by? step?
  lseq start count count ??by? step?
- lseq count ?by step?

It'd be much simpler and more consistent. But it'd be just nice to have.

Dear Nathan, Jan,

please allow me to give my limitted view:

In the form "lseq 3.0" the argument "3.0" is a count for a sequence.

That a coung beeing a float or an entier gives the final format is IMHO "interesting functionality" hard to explain to an end user.

For me, this feels quite critical, as float and entier work quite differently internally. float have roughly 15 significant digits while entier is unlimited.

Specially here is clear that the count is an entier:

% lseq 3.5
expected integer but got "3.5"

Controlling the type of the return value is possible by the "by" clause. This is logical and ok for me:

% lseq 3 by 1
0 1 2
% lseq 3 by 1.0
0.0 1.0 2.0

So, I would say, that "lseq 3.0" returning floats is a bug, or at least, a feature hard to explain to the end user. Or do I miss the big picture?

Thank you and take care, Harald

But overloading parameters like that almost always leads to trouble.

Then it should at least be documented.

This looks like a feature to me, not a bug.