Updated 2015-02-20 03:36:23 by pooryorick

llength returns the number of elements in a list.

Documentation  edit

official reference

Synopsis  edit

llength list

Description  edit

Returns the number of elements in list. If list is not a well-formed list, an error is thrown.

caspian: Make sure to give llength the list, not just the name variable where the list is stored. For example:
# This is the right way to do it.
set mylist {a b c}
# LV writes: technically, _this_ is the right way to do it, at least
#  for cases more complex than a simple a, b, and c...
# set mylist [list a b c]
llength $mylist

# This is the WRONG way to do it.
# This won't return an error, but it will always return "1",
# no matter how long or short your list is.
set mylist {a b c}
llength mylist

This is one of those places where Tcl's treatment of bareword literals can be frustrating to someone.

In the second case above, Tcl considers the argument to llength a list. Therefore, it is going to return the length of the list, which is equivalent to this list:
llength [list mylist]

DKF: The phrase "bareword literals" indicates a deviation from the Tcl Way; the concept does not really operate usefully in Tcl, unlike in a number of other languages (*cough*Perl*cough*). llength always works with list values, and lists are always values. If you've a list in a variable, you need to get the list out of the variable to work out its length.

LV: Technically, the problem the original writer hit isn't Tcl (as an interpreter), but llength. The documentation clearly indicates that llength takes a list as its argument. When llength looks at its argument, it sees the string mylist , which is a list - a single entry list. It sees the same way in each of these cases:
llength mylist
llength "mylist"
llength {mylist}
llength [list mylist]

In each of these cases, llength sees the list/string mylist and NOT the value of the string.

The problem here is that some of the Tcl l* commands expect the name of a variable, while others expect the value itself. And it is up to the developer to keep straight the two types of requirements.

I suspect that caspian was just frustrated that Tcl doesn't require you to have something around mylist to indicate that it is data. Many other languages require data to be deliminated by quotes of some sort. The fact that single-word strings (i.e. bareword literals) are permitted in Tcl can be frustrating for people (even old-timers....).

escargo finds the fact that bareword literals are permitted some places and not others to be the frustrating thing.

slebetman: Actually bareword literals (since we're using that term here) are permitted everywhere.. except in expr where one needs to quote strings. I suspect the frustration is not about literals per se, rather it is about whether a command accepts a value or a variable name. Thinking about it like this makes you realise that the same problem exists in other languages albeit with different syntax:
/* C example */
int *i;

/* Assume i is pointing to something valid */
/* Pass by value : */

/* Pass by reference : */

# Similarly in Tcl
# Assume i exists
# Pass by value:
byValue $i

# Pass by name:
byName i

GWM: Note also the slightly unexpected result for:
# returns 3 as the string (only one string) is interpreted as a list by
# llength, the spaces making 3 words. 
llength {a b c}

# is also 3 - the inner braces make a sub-list
llength "a {b d} c"

# also 3 - it is the same as above
llength {a {b d} c}

# is 1 - the braces inside the string make a sub-list
llength "{a {b d} c}"

Also note the difference between braced lists and quoted in this case:
set a {a b c}
llength "1 2 $a 3" ;# 6 words in the substituted list
llength {1 2 $a 3} ;# 4 words in the list (which does not have $a substituted)

See also  edit