Zeev,
- For comments on general, you might want to join the IRC channel #marpa on irc.freenode.net, c.f. https://groups.google.com/d/msg/marpa-parser/ZIZ003_GUig/3ti4II8HRrgJ - For the particular "TOP 5" case, this is just a grammar extension like GNU or MS did to the C language. - What about adding this explicitely to the grammar, then? If you are ready to fork the repo on github, try, and confirm this is ok, I can release that. Perhaps with a special flag... ? - From https://groups.google.com/d/msg/marpa-parser/ZIZ003_GUig/3ti4II8HRrgJ I see this can differ between multiple SQL implementations. So suppose I add parameters like: - -- extension top (in the command-line) - extension => {top => 1} (in the API) ... wil that be ok for you ? Le jeudi 8 janvier 2015 20:25:25 UTC+1, Zeev Atlas a écrit : > > The most important case that I have in mind is the SQL Server 'SELECT TOP > 5 col1, col2, ...'. Wouldn't the Pre-lexeme event be better then the > Rejection in that particular case? I am reading the documentation as is > written now [ > http://search.cpan.org/~jkegl/Marpa-R2-2.101_000/pod/Event.pod#The_life_cycle_of_events]. > > The events and their use is not always clear from the documentation. > You've mentioned that what I want to achieve could be done in various ways > and I assume that you meant by judicious use of the events. I need a bit > of help here, like better, less formal and more example oriented > explanation of the events. > Thank you > 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]> 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]. >>> 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.
