[GRASS5] Re: intersect sites with polygons?

[Glynn Clements]

Christoph Simon wrote:

> This means, at any point, there must be an association between the
> operator and the function performing the operation: Any binary
> operator will always yield a function call. This can be context bound,
> i.e., the CONATINS operator may have a different meaning (calling a
> different function) according to the operator type which might be a
> map or not. It's more, I plan to allow creating arrays of operator to
> function association, so a user could create her own context, loading
> for instance a function which will always/never deal with attributes
> in a certain way (like accessing SQL). Unless there is a fixed and
> clearly defined set of standard operators, I really think we should
> wait with this until having something working and a minimum set of
> functions. To test these functions, we always can use the function
> call syntax rather than the operator syntax. In any case, the operator
> syntax basically is programmed, it's just a question of replicating
> the things for CONTAINS as they are done with '+'.

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.

> > and "." (dot) may be used in map names). 
> 
> I did think about this, but there are very few characters which are
> not allowed in the filesystem and which are not already used else
> (like / which is used for division). I chose the dot because I thought
> it's not very common for map names and there is a way out: First one
> could say "map.new.[]". Only the last dot is used, and an empty
> bracket would indicate all. When the lexical scanner is working, there
> will be a special object called string, which can be really anything
> within double or quotes. So quoting "map.new" means that "new" is an
> extension and not a selection, while just map.new would try to
> interpret the "new" as a selector. How frequent do you think are dots
> in mapnames?

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.

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

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.

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