[GRASS5] Re: intersect sites with polygons?

[Christoph Simon]

On Wed, 3 Jul 2002 05:34:40 +0100
Glynn Clements <glynn.clements at virgin.net> 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. So I plan to follow your suggestion at least at the
beginning until a fixed set of operators is known. The fact is that
there is no prefix/infix notation which can't be expressed by a
function call syntax, and each prefix/infix syntax will internally
always lead to a function call.

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

> Also, I suggest allowing the use of quotes for map names which contain
> "special" characters, as is the case for r.mapcalc (e.g. test-map is
> parsed as a subtraction, but "test-map" and 'test-map' are parsed as a
> map name).

This is aready started, though not finished. I've a flex script which
will do this for properly paired single and double quotes with the
same meaning.

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

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.

Neither of the two where clear and easy decisions, but since I made
them, I'm happy with them. As I plan to use readline for interactive
usage, single line statements are nice, because they are easy to
repeat and edit. In this case a newline would be just fine. But since
I was always considering more complex idioms like conditionals and
loops, the usage of scrips and include files, the newline character as
an end of statement can be really limiting. Last but not least, the
fact that psql (postgres) does use this character, shows that this
idea isn't completely absurd.

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