I agree with you guys and would prefer a rule based solution. I am not sure what would be the differences among the various ideas that have been explored here, but obviously (in layman terminology) the preferred solution would be to have the Microsoft (SQL Server), Oracle, MySQL and all other vendors' extensions present, preferably in their own subsections (I assume that this is what you guys mean by sub-grammars). As I've stated in this and past conversations, there are two obstacles: 1. Such grammars are not readily published/available (and perhaps are even kept quasi-secret or intentionally obfuscated), so they should either be developed or somehow extracted from obfuscated documents. And this bring me to my second, clearly stated, disadvantage, namely 2. I do not, even if I managed to extract such grammars, posses the knowledge of how to put them in correct BNF format and how to add them, sub-grammars or otherwise to the existing ones. Again, I added it to my list to study that stuff, but the learning curve would be pretty stiff. Also, I did not yet have managed to find any place where Microsoft clearly publishes their extensions. Preliminary evaluation of Oracle publications showed me that extracting their rules and discern their extensions would be a project unto itself. And I did not even try to look at MySQL and others.
For the current project in its current state, I will certainly look at Jeffrey's code and see how to adapt it Thank you and have a Happy New Year ZA On Wednesday, December 31, 2014 12:24:58 PM UTC-5, Jeffrey Kegler wrote: > Zeev -- the sort of thing you suggest can be done, in various ways. You > can pause the parse, switch to manual parsing, and resume the input at an > input location of your choice. > > As an example of this sort of thing, I recently did my own example of > delimiter handling > <http://jeffreykegler.github.io/Ocean-of-Awareness-blog/individual/2014/11/delimiter.html> > > which, when it encounters a missing delimiter, supplies it. > > The reason I think you see the others (and myself) preferring a direct, > rule-based, approach is that it makes for simpler, faster and more > maintainable code, when it is possible. And what with the wide variety of > grammars that Marpa can parse, plus various tricks such as ranking rules, > it often is possible. > > On Wed, Dec 31, 2014 at 4:37 AM, Zeev Atlas <[email protected] > <javascript:>> wrote: > >> As I read more and begin to grasp the complexity of Marpa solution, and >> the desire to work all issues from within the context of grammar, actions >> (evemts, etc.) I can see why you guys want to insist on using rules and >> only rules, whether positive or negative, to parse the subject. Let me >> please givee you a counter argument: >> I am not a native English speaker. When I learned the language, till >> today, when reading and parsing text, i may and do encounter words that I >> do not know. Instead of going to the dictionary, I encapsulate such words >> and substitite them with either a context based approximation or with null >> and try to continue parsing. Rarely, indeed very rarely, I cannot proceed. >> What I would want is something similar, in which Marpa would tell me that >> it have encountered such an element and allow me to advise it to substitute >> it with something else or nullify it and continue. >> I do not know how hard is that to implement, but I suspect that it should >> not be that hard. And the practical benefits would be enormous >> ZA >> >> -- >> You received this message because you are subscribed to the Google Groups >> "marpa parser" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "marpa parser" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
