Sorry all, I did not mean you should reference the document. I was only
pointing out that the grammar is well-defined and I would like to stick to
these definitions as much as possible.
That being said, I have thought about it and it seems this issue is not one
that can be resolved by the parser. Consider:
reg [3:0] x[7:0][7:0];
Consider this reference to x:
Here the last index should be an expression. Consider this reference to x:
Here the last index should be a range expression.
In other words, the type of the last index depends on the attributes of the
variable itself, so it cannot be discerned without knowing how the variable
was declared. I have created a work-around after parsing, but I was hoping
that the parser could the resolve the issue on its own.
I really appreciate all of your help!
On Mon, Jan 23, 2012 at 1:49 PM, Ryan Molden <ryanmolden@...> wrote:
> On Mon, Jan 23, 2012 at 11:22 AM, Stewart, Robert <Robert.Stewart@...:
>> What I meant by that is without seeing your definition of expression, how
>> can we know why it is consuming what you meant the optional
>> range_expression to match?
> I think the problem is tractable without that, but I agree in the general
> sentiment that assuming we
> a) Know Verilog
> b) Want to read some IEEE spec to answer a mail list question
> is probably not conducive to speedy help :)
> That said, as Seth pointed out, the problem is that what have is
> guaranteed to fail in the face of greedy parser. You have this
> range_expression = lit('[') >> expression >> ':' >> expression >> ']' |
> lit('[') >> expression >> ']'
> primary = identifier >> *('[' >> expression >> ']')
> >> -range_expression
> The problem is the parser that follows identifier consumes the exact same
> input as the second branch of range_expression, so there is no way it (in
> isolation) could possibly know it should leave an otherwise acceptable
> token (expression) so it can be picked up by another parser down the line
> (-range_expression). * is greedy in its consumption so it will always
> gobble as much input as it can. In regex things like this can be solved by
> using non-greedy patterns, of course at the cost of making overall
> processing slower in the fact of things like expression expression
> expression range_expression.
> One approach, is as Seth suggested, to use look ahead to force a non-match
> in situations where you want to leave the last expression alone. Another
> option, is to stop using things like lit('[') >> expression and move to
> describing these things with regexes in lexertl (which supports lazy
> consumption) and convert your parser to operate on the tokens produced by
> your lexer instead of the raw input stream.
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> Spirit-general mailing list