|
From: avl <av...@lo...> - 2017-02-14 15:48:27
|
"Dipl. Ing. Sergey G. Brester" <sebres@us...> wrote:
> if {(arr($y,$xoffs + $k) = sin($v)) > $threshold} {...} {...}
Sorry to disappoint you, but this just isn't likely ever
going to work out-of-the-box with Tip-282
Not "out-of-the-box", but with a little "preparation":
proc tcl::mathfunc::arr {x y} { return "arr($x,$y)" }
it would actually work in current state of tip-282 branch.
That's not a guarantee that it will eventually work in a
release version of Tcl. I even think that's rather unlikely.
> And real pity if it would be impossible, because of some
> artificial use-cases
It's not artificial usecases, but just the way how arrays work
in Tcl (which doesn't differ much inside and outside of expr -
it only subtly differs between $...-subst and ${...}-subst and
[set ...] for the simple reason that for [set] usage the full
"varname" is determined by word-parsing rules, whereas ${...}
is determined by finding next close brace, and $... by finding
either first non-letter/digit/underscore, or, after an (, the
next ). Once the complete name is defined, the structure of the
variable then depends on whether the last character is a close
paren and the first open paren (if one exists) within the name.
PS: don't split hairs over this summary - I haven't let any
lawyer proof-read it.
> Just by the way, I don't like the idea with "magic char" also.
Apart from current state of tip-282 (with quoting var- and array-
names, or using results of sub-expressions as names), it's the only
other way to also support array-element-assignments.
> The idea I try to follow (and explain the whole time), is to recognize
> the assignment and use the lvalue as variable name in assignment case.
When compiling an expression like {sin(0)=42}, then at the time the "=" is
seen, the bytecode for calling [tcl::mathfunc::sin 0] is already produced.
|