Glynn Clements wrote:
More generally, I think that we should reconsider the behaviour of
assignment. Currently, the semantics are far from clear.
At a minimum, we should probably refactor the grammar, so that
top-level assignments (i.e. map creation) are handled separately to
variable assignments.
I've now done that, and made a couple of other minor alterations. The
consequences of the change are:
1. You can now use quoted names on the LHS of an assignment.
2. You can now reference qualified (map@mapset) maps where one of the
two parts happens to be a variable name without having to use quotes.
3. You can now access functions which have the same name as a
variable.
4. A top-level statement which isn't an assignment now generates a
parse error rather than an internal error.
5. You can no longer create a map with the name of an existing
variable. A corollary of this is that you can no longer create a map
twice.
Points 1-4 shouldn't be contentious, as they should only affect inputs
which would previously resulted in an error.
Point 5 is based on the assumption that explicit failure is usually
preferable to a silent wrong answer. It eliminates the risk of:
r.mapcalc "a = ... ; $foo = ... ; b = a"
silently producing bad data for b where $foo happens to be "a".
Behaviour which is unchanged includes:
1. Map definitions also create a variable which can be read in
subsequent expressions.
2. Variables can be "overwritten" (more accurately: reassigned).
A substantial number of scripts rely upon these two points (primarily
point 1, although at least shade.rel.sh relies upon point 2).
The situation still isn't ideal, IMHO, but I'm not sure what else can
be done while maintaining compatibility with the original r.mapcalc
(and with existing scripts). Although, it might be possible to
restrict variable assignments (not counting map definitions) to within
eval(); all of the cases which I've seen fit into that pattern.
--
Glynn Clements <glynn.clements@virgin.net>