On Sat, Jan 4, 2014 at 9:05 PM, amon <[email protected]> wrote: > In the last few days I've thrown together a prototype for Yet Another > DSL-frontend for Marpa. The design problems are solved quite differently > from the SLIF, as neither performance nor the quality of error reports were > deemed important for this prototype. The DSL is therefore happy to > autogenerate rule names for syntactic sugar like inline quantifiers or > nested rules. For me, the most important feature is that actions are > specified inside the grammar (and then "eval"'d). > > Ultimately, the DSL intends to be (a) useful for prototyping of small > (programming-)languages without too much boilerplate code and (b) a simpler > interface for people not too familiar with parsing. It does not intend to > be an unrestricted interface to Marpa. > > The project can be found on https://github.com/latk/Marpa-Inline, and > contains two examples in the "t/examples/" directory. A few topics are not > addressed by this prototype, most importantly: > > - Error reporting > - Operator Associativity > - Events > > If your interface is built as a syntactic extension of SLIF (it seems to be from what I've seen in the repo, except for lexing, on which see next paragraph) and you're going to preserve some features of SLIF, then, perhaps, rather than rolling your own grammar and compiling to SLIF, you can take SLIF metagrammar<https://github.com/jeffreykegler/Marpa--R2/blob/master/cpan/lib/Marpa/R2/meta/metag.bnf>, change it as needed for your extensions and compile *it* back to SLIF.
On the lexing side, you may find external lexing<https://github.com/jeffreykegler/Marpa--R2/blob/master/cpan/t/sl_external1.t>useful — this way your extensions can be used with other Marpa interfaces (directly only with SLIF, but adaptable to others). Because of that (and the overengineered, buggy internals), I will likely > rewrite it. I would be glad to include any feedback the list could offer in > the rewrite. Especially, I'm not sure about: > > - … disallowing non-ranked alternatives. This should feel more > comfortable for people familiar with regexes or procedural parsing. I am > aware that this throws away one of Marpa's major strengths, but I see no > use cases. > > If you choose to syntactically extend SLIF > metagrammar<https://github.com/jeffreykegler/Marpa--R2/blob/master/cpan/lib/Marpa/R2/meta/metag.bnf>, this seems to be a non-issue: just leave it for those who'd need it, if any. > > - … the name. Currently the classes reside in the > "MarpaX::DSL::InlineActions" namespace. The "MarpaX" namespace is loosely > organized, and e.g. has the `::Languages::Foo` section for tools using > Marpa operating on language Foo. What is the correct section for > alternative frontends? Would "::DSL::Foo" or "::Frontend::Foo" be a good > choice? Currently existing modules fitting this categorization would be > "MarpaX::Repa", "MarpaX::Simple::Rules", "MarpaX::Lex::Easy", none of which > are well-named. > > *new DSL (as an extension to/rewrite of SLIF)* As I can see from the repo, it is the *inline *rules and actions where most emphasis is, so I'd suggest MarpaX::DSL::Inline or perhaps, as it's like SLIF, that's an interface, MarpaX::Interface::Inline -- . *(external) lexing (longest-acceptable-token matching and perl regexes)* -- if you opt for external lexing, this can be useful as a separate module MarpaX::Lexer::External or just MarpaX::Lexer (::External is implied by the separation of the module from Marpoa::R2) is a good name for code that allows plugging in external lexers in general, while MarpaX::Lexer::<Specific_External_Lexer_Name> looks good for particular lexers. *less boilerplate (**->new(string => $grammar)->parse($source)**) *-- can be useful for others as is, so can go to a separate module, like, e.g. https://metacpan.org/pod/Grammar::Marpa MarpaX::Parser or MarpaX::Parse — IIRC, I had it registered for my now abandoned project<https://github.com/rns/MarpaX-Parse> q year ago, but I've never released anything and will be happy to deregister. Still, all of the above can be considered part of your interface to Marpa and thus can form part of MarpaX::DSL::Inline or MarpaX::Interface::Inline or whatever name you choose for your interface. Hope this helps. -- > 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/groups/opt_out. > -- 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/groups/opt_out.
