Dear Tk community,

please allow me to inform you about a private communication with Jan
which enlighted me about recent Tk concepts.

I had asked, why the result of the functions of TIP621 resturn the empty
string if not found and a character position if found.

Here is the question and the answers by Jan.
Enjoy,
Harald

Op wo 6 apr. 2022 om 19:45 schreef Harald Oehlmann:

If found, a position is returned. If not found, the empty string is returned. I suppose, it would be better to return "-1", if not found.

Well, this is 100% as intended. See:
<https://core.tcl-lang.org/tips/doc/trunk/tip/577.md>

I always found it strange in Tcl and Tk that "-1" is used as
"not-found". In my opinion, "" would be more logical. I'm
preparing
<https://core.tcl-lang.org/tips/doc/trunk/tip/615.md>
to do the same in Tcl as in Tk. If we accept more than only
integers as index value, why not "" as well?

I realize that it has a lot of impact in Tcl, if we change all
functions returning "-1" to return "" instead. It means that
all scripts cannot use this any more:
if {[some command] == -1} {
}
they need to change that to:
if {[some command] < 0} {
}
(since "" is smaller than 0 too, this works with both "" and -1)
Therefore, this can only be done in Tcl 9.0, and possibly
not for all commands yet.

Since Tk is consistent now (when building with Tcl 9.0,
all search-functions return "", not -1) better let new
functions behave like this from the start ....

Hope this helps,
Jan Nijtmans

----
P.S. by Harald:
I personally always avoid the mixing of data types due to shimmering.
So, a check like "if {$Index eq ""}" would transform a present number to
a string. This may be avoided by "if {$index == -1}". And a check "if
{$Index < 0}" to test for the empty string is IMHO not at all transparent.
But, as usual, I don't see the whole picture and think to small....

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le jeudi 7 avril 2022 à 11:46:25 UTC+2, Harald Oehlmann a écrit :

Dear Tk community,

please allow me to inform you about a private communication with Jan
which enlighted me about recent Tk concepts.

...

----
P.S. by Harald:
I personally always avoid the mixing of data types due to shimmering.
So, a check like "if {$Index eq ""}" would transform a present number to
a string. This may be avoided by "if {$index == -1}". And a check "if {$Index < 0}" to test for the empty string is IMHO not at all transparent. But, as usual, I don't see the whole picture and think to small....

Hi Harald,

I totally agree with you, I avoid shimmering in my code too, and I find mixing result type of default Tcl commands a totally bad idea.
I wonder how the TIP 577 as been accepted, with such "Compatiblity" section. Also Jan already started to update Tk code (trunk and branch 8.6) do do the same with [lsearch]...

Eric

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Eric <[email protected]> wrote:

Le jeudi 7 avril 2022 à 11:46:25 UTC+2, Harald Oehlmann a écrit :

please allow me to inform you about a private communication with Jan
which enlighted me about recent Tk concepts.

...

P.S. by Harald:
I personally always avoid the mixing of data types due to shimmering.
So, a check like "if {$Index eq ""}" would transform a present number to
a string. This may be avoided by "if {$index == -1}". And a check "if
{$Index < 0}" to test for the empty string is IMHO not at all transparent. >> But, as usual, I don't see the whole picture and think to small....

I totally agree with you, I avoid shimmering in my code too, and I find mixing
result type of default Tcl commands a totally bad idea.
I wonder how the TIP 577 as been accepted, with such "Compatiblity" section. Also Jan already started to update Tk code (trunk and branch 8.6) do do the same with [lsearch]...

me, 3 ;-)

I find it very hard to believe that TIP 577 (that I find very good for Tk,
in particular where it replaces other special word "none")
would include extending it from Tk to Tcl core commands.

Suggesting "< 0" is also quite short-sighted in the context that kbk once suggested to restrict the inequality-operators to numeric arguments only,
to make them "transitive", which they are currently not, as long as
comparisons of numbers and strings are possible ( 1 < 0x2 < 0y < 1 ) .

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

* Harald Oehlmann <[email protected]>
| Here is the question and the answers by Jan.
| Enjoy,
| Harald

| Op wo 6 apr. 2022 om 19:45 schreef Harald Oehlmann:
--<snip-snip>--
| I realize that it has a lot of impact in Tcl, if we change all
| functions returning "-1" to return "" instead. It means that
| all scripts cannot use this any more:
| if {[some command] == -1} {
| }
| they need to change that to:
| if {[some command] < 0} {
| }
| (since "" is smaller than 0 too, this works with both "" and -1)
| Therefore, this can only be done in Tcl 9.0, and possibly
| not for all commands yet.

Jeez, this would (will??) be a nightmare in TCL 9!

Many of our scripts depend on [lsearch] or [string] returning -1 as it
is documented now. If -1 was not mentioned explicitely in the docs
(eg. "returns a value < 0"), one could argue about it. But changing
this to return "" instead of -1 would break compatibilty for little to
no adavantage at all :-(

Please DON'T!

R'

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

returning "" as a none found result is common when the result is a list. I'm not sure it is a good idea when an index is expected. "" is a valid index in some cases, but it does not necessarily imply nothing is selected. For example:

# a list for examples
set ll {1 2 3 a b c}

lsearch -all $ll k

#returns an empty list ""

#however

lsearch $ll k

#returns a valid index -1 (nothing found)

#under the current system

lindex $ll [lsearch $ll a]

#returns "a"

#and

lindex $ll [lsearch $ll k]

#returns "", a reasonable result.

#However under the proposed change it would return the complete list.

lindex $ll ""

#currently returns the whole list, which makes sense in the context of nested list indexes. But not as the resut of a search.

Dave B

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

At Fri, 08 Apr 22 14:55:01 GMT [email protected] wrote:

returning "" as a none found result is common when the result is a list. I'm not sure it is a good idea when an index is expected. "" is a valid index in some cases, but it does not necessarily imply nothing is selected. For example:

# a list for examples
set ll {1 2 3 a b c}

lsearch -all $ll k

#returns an empty list ""

Correct -- this is documented.

#however

lsearch $ll k

#returns a valid index -1 (nothing found)

#under the current system

lindex $ll [lsearch $ll a]

#returns "a"

#and

lindex $ll [lsearch $ll k]

#returns "", a reasonable result.

#However under the proposed change it would return the complete list.

lindex $ll ""

So what would you expect

lindex $ll [lsearch -all $ll k]

to return???

If you are doing [lsearch -all ...] it makes no sense to pass the result to lindex. What you want is something like:

set allks [list]
foreach inx [lsearch -all $ll k] {
lappend allks [lindex $ll $inx]
}
puts $allks

Which given your example list, prints an empty list.

#currently returns the whole list, which makes sense in the context of nested list indexes. But not as the resut of a search.

Dave B

--
Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
[email protected] -- Webhosting Services

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 4/7/22 5:46 AM, Harald Oehlmann wrote:

Dear Tk community,

please allow me to inform you about a private communication with Jan
which enlighted me about recent Tk concepts.

I had asked, why the result of the functions of TIP621 resturn the empty string if not found and a character position if found.

Hello,

I think the current approach makes sense and fits nicely with the likely
next steps in the computational flow: process the matches within a loop,
for instance. If no match, no code changes will be needed to handle the
flow.

If the no-match case returns the original list, how would you know if
there was a match or not? Imagine a case where you need to highlight
the matches for the user. You will have to compare the original full
list against the returned list; which may still be inadequate in case of
a perfect/full match. This could be more costly wrt code and time, but
also not quite intuitive.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Robert Heller <[email protected]> wrote:

At Fri, 08 Apr 22 14:55:01 GMT [email protected] wrote:

# a list for examples
set ll {1 2 3 a b c}

...

lindex $ll [lsearch $ll k]
#returns "", a reasonable result.
#However under the proposed change it would return the complete list.
lindex $ll ""

So what would you expect
lindex $ll [lsearch -all $ll k]
to return???

Nothing useful, of course.
And it was not clt.to.davebr's example.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Andreas Leitgeb schrieb am Freitag, 8. April 2022 um 23:25:00 UTC+2:

Robert Heller <[email protected]> wrote:

At Fri, 08 Apr 22 14:55:01 GMT [email protected] wrote:

# a list for examples
set ll {1 2 3 a b c}

...

lindex $ll [lsearch $ll k]
#returns "", a reasonable result.
#However under the proposed change it would return the complete list.
lindex $ll ""

So what would you expect
lindex $ll [lsearch -all $ll k]
to return???

Nothing useful, of course.
And it was not clt.to.davebr's example.

April joke?
I remember how the core developers behave much restrictive about changing things.
Changing this function would turn available Tcl codes around the code into a nightmare.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)