This project has moved and is read-only. For the latest updates, please go here.

Ambigous Expressions

May 21, 2014 at 6:10 PM
Edited May 21, 2014 at 7:10 PM

I've a got a working Sql grammar but now need to be able to parse "ambiguous" expressions. So for example

WHERE name='o'reilly'
WHERE name='thomas''

I'm not sure of the approach I should be taking to implement this. I was wondering if someone could provide some general guidance. I imagine that I'd need to just accept everything that is to the right of the "=" into something general which could be evaluated further down the line.

I was thinking of producing my own Terminal to try to capture this ambiguity. Alternatively perhaps I should leave the existing grammar as unambiguous and should the parse fail then delegate to something else more general.

Any suggestions would be gratefully received.

May 21, 2014 at 7:37 PM
sorry, don't quite get it what ambiguity you mean, and why existing SQL grammar sample does not work for you. Embedded quote? it should be doubled inside strings, according to SQL rules, and everything should work... please explain
May 22, 2014 at 4:35 AM
Edited May 22, 2014 at 5:09 AM
Roman thx for replying.

The issue I'm facing is that the system I am working with already has data stored in the above format or permits data to be entered in that format. I need to be be able to parse the expression in order to find those area which do not meet the SQL rules. So rather than the parser throwing out the above expression it allows it to be parsed "successfully"(!) so that I can walk the resulting tree and find out which nodes need to be "cleansed" in order for proper Sql to be generated.

Perhaps I'm not thinking about it in the right way though.

As I think about it, I guess what you are saying is that rather than parsing "successfully" and returning malformed nodes, the result of the unsuccessful parse would alert me to the ambiguity and I should deal with it at that stage so I just need to make my current parsing process a bit more interactive.

However, even going down this route, I'm still a bit unsure as to the best way to to de-construct the original expression so as to find the offending part without parsing.

Thx again.

May 22, 2014 at 10:39 PM
I don't have a clear solution; the problem is the 'detection' algorithm, as in informal description of how to catch and fix these errors. Try to formulate it, and then implement as a custom string literal-like terminal
May 23, 2014 at 4:57 AM
OK. Thx very much Roman