Parentheses a bit more useful
ZB
*any* index? I mean: not just for arrays, like it works today - but for lists
and dictionairies as well.
Could it be technically possible? There are some related checks in the
code anyway, which are examining "are the parentheses used really for an
array" - for example:
#v+
% set a 1
1
% puts $a(x)
can't read "a(x)": variable isn't array
#v-
So perhaps there could be additional checks: whether a is an array, _OR_ a
is a list, _OR_ a is a dictionary? Such way we could retrieve a list element
just with $aList(3) - and similarly get the dictionary value - instead of
filling the script with sequences of [lindex $aList 3] (or "dict get").
And I'm wondering: couldn't be technically possible to similarly shorten
the "famous" expr syntax just to something like: [{3+4}]? Seems to be pretty
obvious: "when `{' directly after `[' - it must be expr(ession)"...
--
Zbigniew
Donald Arseneau
> I'm wondering: wouldn't be convenient, to set the parentheses as place for
> *any* index? I mean: not just for arrays, like it works today - but for lists
> and dictionairies as well.
You have to choose lists *or* dictionaries, because dictionaries *are* lists.
set list {1 1 2 3 5 8 13 21 34 55}
Should $list(5) give "8" or "8" oops, bad example :-)
Should $list(2) give "2" (as [lindex]) or "3" (as [dict get])?
Indeterminate.
Having this syntax for [lindex] has been discussed periodically for a long
time; I don't recall the consensus reasoning, but it was not adopted.
It would be a better fit for dict lookup though, given the close kinship
between array and dict.
--
Donald Arseneau as...@triumf.ca
ZB
>> I'm wondering: wouldn't be convenient, to set the parentheses as place for
>> *any* index? I mean: not just for arrays, like it works today - but for lists
>> and dictionairies as well.
>
> You have to choose lists *or* dictionaries, because dictionaries *are* lists.
OK, so I choose lists.
--
Zbigniew
Donal K. Fellows
> You have to choose lists *or* dictionaries, because dictionaries
> *are* lists.
Dictionaries aren't lists, but they have the same basic syntax. At a
higher level, they have some constraints on the keys, and they
represent something entirely different (sparse value-to-value maps,
rather than compact cardinal-to-value maps). What is true is that any
dictionary can be interpreted as a list, with only effects due to
performance.
Donal.
Donald Arseneau
> On 29 Aug, 05:35, Donald Arseneau <a...@triumf.ca> wrote:
> > You have to choose lists *or* dictionaries, because dictionaries
> > *are* lists.
>
> Dictionaries aren't lists, but they have the same basic syntax.
Huh!? Surely all dictionaries are lists, but not all lists are
dictionaries. Just as all commands are lists but not all lists
are commands. Just as all dictionaries are strings and all lists
are strings, but not vice versa.
> What is true is that any dictionary can be interpreted as a
> list, with only effects due to performance.
One might revert Tcl to be entirely string-based internally, with
only effects due to performance.
--
Donald Arseneau as...@triumf.ca
ZB
> Huh!? Surely all dictionaries are lists, but not all lists are
> dictionaries. [..]
Actually, the point is: can variable be distinguished as dictionary, not a
"pure" list? It seems, it can be:
#v+
% set a [dict create x 1 y 2]
x 1 y 2
% dict get $a x
1
% set b [list 1 2 3]
1 2 3
% dict get $b 0
missing value to go with key
% dict get $b 1
missing value to go with key
% dict get $b 2
missing value to go with key
% dict get $b 3
missing value to go with key
#v-
See? "b" is list - but tclsh didn't try to return "dictionary value". So it
can be detected somehow.
If so, my proposal is to keep recognition order, I mean: "Is variable an
array, or is it a dictionary, or is it a list"; that's enough to avoid
confusion.
--
Zbigniew
Andreas Leitgeb
> Dnia 30.08.2010 Donald Arseneau <as...@triumf.ca> napisał/a:
>> Huh!? Surely all dictionaries are lists, but not all lists are
>> dictionaries. [..]
> Actually, the point is: can variable be distinguished as dictionary, not a
> "pure" list? It seems, it can be:
> #v+
> 1 2 3
Retry all that below with an even-sized list - say [list 1 2 3 4].
> % dict get $b 0
> missing value to go with key
> % dict get $b 1
> missing value to go with key
> % dict get $b 2
> missing value to go with key
> % dict get $b 3
> missing value to go with key
> #v-
You surely didn't mean letting $var(0) mean [lindex $var 0]
for odd-sized, and [dict get $var 0] for even-sized lists...
Frédéric Bonnet
That's why keyed and indexed access methods must use distinct syntaxes. For
example $dict(key) and $list{index} (we can't use the C-like $list[index]
because brackets are for command substitution).
tom.rmadilo
> See? "b" is list - but tclsh didn't try to return "dictionary value". So it
> can be detected somehow.
>
> If so, my proposal is to keep recognition order, I mean: "Is variable an
> array, or is it a dictionary, or is it a list"; that's enough to avoid
> confusion.
The only thing you can distinguish is an array from a regular
variable. An array variable cannot be a list or a dictionary or a
scalar. Some lists can be ruled out as being valid dictionaries. But
even a valid dictionary could not look like a dictionary to a
particular key list.
Don't get your hopes up here. Tcl isn't meant to help you "know" the
datatype of anything.
ZB
> The only thing you can distinguish is an array from a regular
> variable. An array variable cannot be a list or a dictionary or a
> scalar. Some lists can be ruled out as being valid dictionaries. But
> even a valid dictionary could not look like a dictionary to a
> particular key list.
OK - anyway, as list is a datatype using in TCL scripts quite extensively,
wouldn't be worthy to use the parentheses, to dispose the need of filling
the scripts with that "[lindex $x $y]"?
Look at the example below:
#v+
foreach face $lcnx {
foreach {nx ny nz} [CrossProduct \
[expr {[lindex $lvtx [lindex $face 1] 0] - [lindex $lvtx [lindex $face 0] 0]}] \
[expr {[lindex $lvtx [lindex $face 1] 1] - [lindex $lvtx [lindex $face 0] 1]}] \
[expr {[lindex $lvtx [lindex $face 1] 2] - [lindex $lvtx [lindex $face 0] 2]}] \
[expr {[lindex $lvtx [lindex $face 2] 0] - [lindex $lvtx [lindex $face 1] 0]}] \
[expr {[lindex $lvtx [lindex $face 2] 1] - [lindex $lvtx [lindex $face 1] 1]}] \
[expr {[lindex $lvtx [lindex $face 2] 2] - [lindex $lvtx [lindex $face 1] 2]}]] {}
}
#v-
Do you like it?
And yes, I'm aware, that I can make the code a bit less verbose by introducing
additional, indirect local variables. But it's "workaround, not a solution".
Compare the above with this, what _could be_ :
#v+
foreach face $lcnx {
foreach {nx ny nz} [CrossProduct \
[expr { $lvtx($face(1) 0) - $lvtx($face(0) 0) }] \
[expr { $lvtx($face(1) 1) - $lvtx($face(0) 1) }] \
[expr { $lvtx($face(1) 2) - $lvtx($face(0) 2) }] \
[expr { $lvtx($face(2) 0) - $lvtx($face(1) 0) }] \
[expr { $lvtx($face(2) 1) - $lvtx($face(1) 1) }] \
[expr { $lvtx($face(2) 2) - $lvtx($face(1) 2) }]] {}
}
#v-
Much less typing, better readability...
--
Zbigniew
Donald G Porter
> Look at the example below:
The example is within an expression.
Why not use custom functions there for nicer appearance?
tom.rmadilo
> Dnia 30.08.2010 tom.rmadilo <tom.rmad...@gmail.com> napisa³/a:
>
> > The only thing you can distinguish is an array from a regular
> > variable. An array variable cannot be a list or a dictionary or a
> > scalar. Some lists can be ruled out as being valid dictionaries. But
> > even a valid dictionary could not look like a dictionary to a
> > particular key list.
>
> OK - anyway, as list is a datatype using in TCL scripts quite extensively,
> wouldn't be worthy to use the parentheses, to dispose the need of filling
> the scripts with that "[lindex $x $y]"?
>
> Look at the example below:
>
> #v+
> foreach face $lcnx {
> foreach {nx ny nz} [CrossProduct \
> [expr {[lindex $lvtx [lindex $face 1] 0] - [lindex $lvtx [lindex $face 0] 0]}] \
> [expr {[lindex $lvtx [lindex $face 1] 1] - [lindex $lvtx [lindex $face 0] 1]}] \
> [expr {[lindex $lvtx [lindex $face 1] 2] - [lindex $lvtx [lindex $face 0] 2]}] \
> [expr {[lindex $lvtx [lindex $face 2] 0] - [lindex $lvtx [lindex $face 1] 0]}] \
> [expr {[lindex $lvtx [lindex $face 2] 1] - [lindex $lvtx [lindex $face 1] 1]}] \
> [expr {[lindex $lvtx [lindex $face 2] 2] - [lindex $lvtx [lindex $face 1] 2]}]] {}
> }
> #v-
>
foreach face $lcnx {
foreach {f0 f1 f2} $face {break}
set Cmd [list CrossProduct]
foreach {a b} [list $f1 $f0 $f2 $f1] {
foreach c {0 1 2} {
lappend Cmd [expr {[lindex $lvtx $a $c] - [lindex $lvtx $b
$c]}]
}
}
#puts stderr $Cmd
foreach {nx ny nz} [{*}$Cmd] {}
}
ZB
> The example is within an expression.
>
> Why not use custom functions there for nicer appearance?
Well, actually the example isn't mine - just took it from "polyhedra" demo,
as it is a "spectacular case" of "massive lindex use".
But it's not the point; the point is, that although there are some ways
to modify the example, the use of parentheses would be just more comfortable
for indexing.
--
Zbigniew
Glenn Jackman
Given Don's suggestion:
interp alias {} ::tcl::mathfunc::l {} lindex
if 0 {
#or to be more explicit:
proc :;tcl::mathfunc::l {lst args} {
lindex $lst {*}$args
}
}
foreach face $lcnx {
lassign [CrossProduct \
[expr {l($lvtx, l($face,1), 0) - l($lvtx, l($face 0), 0)}] \
[expr {l($lvtx, l($face,1), 1) - l($lvtx, l($face 0), 1)}] \
[expr {l($lvtx, l($face,1), 2) - l($lvtx, l($face 0), 2)}] \
[expr {l($lvtx, l($face,2), 0) - l($lvtx, l($face 1), 0)}] \
[expr {l($lvtx, l($face,2), 1) - l($lvtx, l($face 1), 1)}] \
[expr {l($lvtx, l($face,2), 2) - l($lvtx, l($face 1), 2)}] \
] nx ny nz
}
--
Glenn Jackman
Write a wise saying and your name will live forever. -- Anonymous