Now that arithmetic leaf in the assertion grammar
can take absolute paths, we have a lot of
/ characters possible in the expressions - most
noticeably the path separators and the 'divides'
operator.
So as of 1.5
arithmetic_leaf:
( arithmetic_expression )
integer_value
real_value
absolute_path
Which means we can have expressions like..
which should be valid..
I suppose this can be worked around, but it
seems to be too complex for my parser to handle
- so I won't say it is unequivocally an ambiguity -
but it is getting close. Can we make it simpler
somehow? Maybe the word 'div' rather than '/'?
Andrew
Andrew Patterson wrote:
Now that arithmetic leaf in the assertion grammar
can take absolute paths, we have a lot of
/ characters possible in the expressions - most
noticeably the path separators and the 'divides'
operator.
So as of 1.5
arithmetic_leaf:
( arithmetic_expression )
> integer_value
> real_value
> absolute_path
Which means we can have expressions like..
a: /root / /path[xxx]/to = /other/ 4
the left hand side would be valid, but the RHS is not - it would need to
be /other[space] /[space]4
I am not wedded to any particular concrete syntax, but I would say that
the approach we should look at is what Humberto Naves in Brazil has
already investigated, i.e. a modified version of Xpath syntax, which
handles all the various operators. As soon as he gets his specification
up on the wiki, we can consider the details (or, for issues like this,
the vanilla W3C spec should provide the answer - anyone care to follow
it up?).
- thomas
the left hand side would be valid, but the RHS is not - it would need to
be /other[space] /[space]4
In my grammar, paths are productions of the grammar, not
lexical objects (i.e. a path is a stream of tokens like
SYM_SLASH V_IDENT SYM_SQUARELEFT V_IDENT etc),
so whitespace is ignored before getting to the
path rules. I think your reference grammar is the same - should
paths be lexical objects instead? That would remove the amiguity
because the lexer could greedily consume path characters
until it got to whitespace..
Andrew
Hi Andrew,
The grammar in the reference parser is at
http://www.openehr.org/svn/ref_impl_eiffel/BRANCHES/specialisation/components/adl_parser/src/syntax/cadl/parser/cadl_validator.y
(search for "absolute_path" hard up on the left side).
We also treat paths as grammar productions, but at a coarser grain that
you - e.g. there is a lexical token type V_LOCAL_TERM_CODE_REF which
stands for things like [at0002]
The use of / characters is undoubtedly one of the reasons our parser has
some ambiguous rules, but it seems to resolve them, I think because if
the '/' is detached from the rest of the path, it becomes a relative
path, and arithmetic expressions can only have absolute paths in them -
the parser will then backtrack and parse it in a different way.
- thomas
Andrew Patterson wrote:
The use of / characters is undoubtedly one of the reasons our parser has
some ambiguous rules, but it seems to resolve them, I think because if
the '/' is detached from the rest of the path, it becomes a relative
path, and arithmetic expressions can only have absolute paths in them -
the parser will then backtrack and parse it in a different way.
Whether the / is detached from the path should have no effect
on the lexical analysis unless the lex rules are built that way (and I
don't think they are).. so the absolute_path grammar sees exactly the
same tokens whether or not there are spaces. That said, you are
probably right that just the parser just deals with the ambiguities
and gets it right.
However, I just took a look at the xpath operators and they
use 'div' for division..
http://www.w3schools.com/xpath/xpath_operators.asp
So if we are looking at having similar expression grammars
to xpath we will probably end up with 'div' as the operator.
Andrew
Andrew Patterson wrote:
The use of / characters is undoubtedly one of the reasons our parser has
some ambiguous rules, but it seems to resolve them, I think because if
the '/' is detached from the rest of the path, it becomes a relative
path, and arithmetic expressions can only have absolute paths in them -
the parser will then backtrack and parse it in a different way.
Whether the / is detached from the path should have no effect
on the lexical analysis unless the lex rules are built that way (and I
don't think they are).. so the absolute_path grammar sees exactly the
same tokens whether or not there are spaces. That said, you are
probably right that just the parser just deals with the ambiguities
and gets it right.
it won't affect lexical analysis at all - the lexical elements in the
reference parser in a path like /content/items[at000]1/events[at0023] are
/
content
/
items
[at0001]
/
events
[at0023]
but by the time the production rule for 'absolute_path' has been
reached, only /content/items[at000]1/events[at0023] will be accepted,
not content/items[at000]1/events[at0023] i.e. if somehow the leading '/'
had been consumed as a division operator - if this did happen, the
parser would backtrack and generate an absolute_path, as well as an
error to do with missing operator or somesuch.
However, I just took a look at the xpath operators and they
use 'div' for division..
oh - that's ugly!
http://www.w3schools.com/xpath/xpath_operators.asp
So if we are looking at having similar expression grammars
to xpath we will probably end up with 'div' as the operator.
maybe we should support both...
- thomas