[GRASS5] Re: intersect sites with polygons?

[Glynn Clements]

Christoph Simon wrote:

> > I would suggest forcing "add-on" functions to use (prefix) function
> > call syntax. Parsing infix expressions requires knowledge of operator
> > precedence and associativity. Allowing the actual parsing rules to be
> > modified dynamically could result in confusion.
> 
> As I use bison which has good support for it, precedence and
> associativity aren't really a problem, but knowing the operators in
> advance is.

The issue isn't in implementation; that would be simple enough. The
issue is to avoid confusing the user. E.g.

	X * Y <op> Z

is either:

	(X * Y) <op> Z
or:
	X * (Y <op> Z)

depending upon the precedence of <op>. If you have lots of
non-standard[1] infix operators of varying precedence, users will
start by making mistakes, and end up bracketing everything just to be
safe.

[1] Anything that C doesn't have is definitely non-standard. And, as
GRASS' users often aren't programmers, anything other than +-*/ is
dubious.

> > Dots are very common, probably more common than underscore or dash
> > (minus). I suggest choosing a character which has meaning to the shell
> > (e.g. "$"), as people tend to avoid using map names which require
> > quoting.
> 
> I didn't like the dash etc., as it is context bound in the parser to
> be distingished from an operator, but I do like the $.

Actually, your suggestion of the colon might be better. It's unlikely
to be common in map names; furthermore, we may eventually wish to
prohibit colons in map names, for compatibility with Windows.

Currently, we allow[1] all 7-bit characters other than control codes,
delete, space, slash, and single and double quotes, with the
restriction that map names cannot begin with a dot.

[1] In the sense of G_legal_name(). I know for a fact that there are
names which are legal according to G_legal_name() but which will cause
some programs to fail (primarily, use of shell metacharacters will
break code which calls system() or popen() without sufficient
quoting).

> > Actually, to minimise the potential for confusion, I suggest
> > maintaining as much compatibility with r.mapcalc (e.g. tokenising
> > rules, operator precedence) as is practical.
> 
> This was also my top guidline. Operator precedence might be completely
> different, as I am sure that rmap + rmap performs something totally
> different than vmap + vmap, but I'm not sure what vmap + vmap will
> actually mean. Most probably this will be a dynamic concept, having
> the possibility to change at runtime.

As you implied in your other message, "+", "*" etc should at least
have the standard precedence and associativity regardless of their
semantics.

> There are two things about r.mapcalc I didn't consider `practical' and
> hence didn't follow it for v.mapcalc: (1) IIRC r.mapcalc does not
> allow an unquoted name to include a number, because "10a" is actually
> "10 a", while v.mapcalc will consider "10a" a name. But as quotes will
> be supported, "10a" will have the same meaning in v.mapcalc (2) the
> end-of-statement in r.mapcalc is the newline character, while
> v.mapcalc will use the semicolon.

1. It's arguable that r.mapcalc should be changed here; the token
sequence ["10", "a"] doesn't have a parse. OTOH, numeric literals are
also valid (and not uncommon) map names, but clearly they have to
tokenise as numeric literals.

2. The new r.mapcalc (src/raster/r.mapcalc3) allows either newline or
semicolon. Ignore src/raster/r.mapcalc; that is no longer used.

-- 
Glynn Clements <glynn.clements at virgin.net>