Tcl Source Code

% lreplace a 1 end 
a
% set x 1; lreplace a $x end
list doesn't contain element 1

This was fixed with [47ac84309b] in [d561a9353].  The resolution makes behaviour uniform on empty lists, resolving everything raised in this ticket.

My earlier remark on the compiled version being "buggy" is, of course, relative to the documented behavior ("first must exist").

Now since you're suggesting to make slightly incompatible, but extremely reasonable updates to the documented semantics: yes, I agree that one single rule should define allowed positions in [lreplace]: make sure that the target range "touches" the input list.

This allows for

  lreplace a 1 end
  lreplace {} 0 end

and precludes

  lreplace a 2 end
  lreplace {} 1 end

So I'm okay if your plan is to update the noncompiled semantics as just described.

As to the compiled version, again, I'd suggest to drastically reduce the ambition of the optimizer (especially the handling of the lrange-equivalent cases known at compile time, since there's no demand).

Further unusual behaviour I don't understand (error suppression for the empty list) is described at http://paste.tclers.tk/3547. Anyone know why that behaviour exists? Do we want it?

lreplace.n does not support the theory that 1-past-the-end is a valid index for lreplace:

"For non-empty lists, the element indicated by first must exist or first must indicate before the start of the list."

The interpreted implementation (referenced in this ticket) agrees with the manual. The compiled version (inconsistently) currently does not - presumably so that end+1 can be used to append.

Before proceeding to fix both these tickets, I think we should agree on whether end+1 indexes should be allowed for lreplace, and if so, start by crafting a clear description for the manual.

Looks like this one is triggering in the *non-compiled* version of lreplace. Ferrieux, am I not seeing an important connection to [e3106247db]?

this seems to be the test that is breaking down. I need more caffeine and crayons before attacking it confident I'm not going to make things worse.

According to kbk on the chat, lreplace a 1 end should Do Nothing Gracefully. lreplace a 2 end should error as it's asking to leave a nonexistent element.

There seem to be more problems ([47ac84309b]) with compiled lreplace clouding the issue. Ugh.

Also, looking at the complexity of the code, I'm wondering whether it's wise to invest so much to optimize such corner cases. I don't find it too demanding to ask a sensible person to use [lrange] instead of [lreplace .. end].

Seems to be a day-one bug of the compiled version of lreplace in [e3106247db]