[GRASS5] Re: intersect sites with polygons?

[Glynn Clements]

Christoph Simon wrote:

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

Well, the trend in language design seems to be moving away from
requiring whitespace. More generally, the trend in language design
seems to be ever-closer compatibility with C; it's open to debate as
to whether this is good or bad, but it's getting pretty clear that
taking an opposite path in any particular instance is going against
the flow.

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

The main factor is the complexity of a typical statement. For
r.mapcalc, the most common usage is a single expression with a few
operators, included on the command line. Beyond that, most expressions
fit on one line, so it's easier to require a backslash for multi-line
statements than to require a semicolon per statement.

OTOH, it sounds as if v.mapcalc is aimed more at substantial scripts
than simple expressions; in which case, multi-line statements may be
far more common. If the overall syntax differs significantly from
r.mapcalc, it may help to pick a different name, to avoid implying a
similarity which doesn't really exist.

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