[GRASS5] Re: intersect sites with polygons?

[Christoph Simon]

On Wed, 3 Jul 2002 19:44:47 +0100
Glynn Clements <glynn.clements at virgin.net> wrote:

> 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.

I agree; the function call syntax is that much cleaner, and this is
what I prefer, though I'm trying to adapt to common usage. My
conversations with Radim seemd to show that he's preferring the
operator style. The reason why I am trying to make this as flexible as
possible is exactly because I don't know the right answer. Maybe
later, when realworld examples are available, it's possible to define
something. In any case, precedence is a dubious business, as it's an
implicit not immediately visible rule. +-*/ is so well known that
nobody should have problems with it, but a modula operator having a
higher or lower precedence that the division is much less known and
yet not restricted to the C-language.

> 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.

Also in Unix, colons as part of a directory name isn't really
legal. Don't know if Mac might have troubles with that.

> > > 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.

Right. Though it's possible to do it, it's most probably not a good
idea to touch those.

> 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.

The scanner doesn't know if the sequence of found tokens will make
sense to the parser, so the difference is wether the scanner sends one
token type name or string with value "10a" to the parser, or two
tokens, one number "10" and one name or string with value "a". If "+"
can be part of an unquoted name, any token separator will be
necessary. My rationale was that it's easier to insert a few more
spaces than to qote such names. OTOH, I don't want to suggest that
r.mapcalc must change the same way. It has been around for many years
and people got used to it. Changing that might have some bad side
effects.

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

I'm not really happy with the idea the newline is necessarily an
end-of-statement mark. For now it's not. It'll be probably best to
delay this until realworld usage can be tested.

-- 
Christoph Simon
ciccio at kiosknet.com.br
---
^X^C
q
quit
:q
^C
end
x
exit
ZZ
^D
?
help
.