Re: lexeme default vs. :default and :lexeme
The logic goes like this. Note the = instead of ::=. This signals that the statement is not a rule, and is non-lexical -- it's location in the file does not matter. Since it's not a rule, it does not take the form LHS ::= RHS2 ... The initial colon was for pseudo-symbols. Since the lexeme default statement is not a rule, it does not have a LHS, so what appears before the equal sign (=) is not considered symbol, pseudo- or otherwise. I am, frankly, less than 100% happy with this logic and my design choices, but there they are. In an ironic way, it does show Marpa's strength. Because it allows and exploits ambiguity, I can unpaint myself out of the corner, by introducing new statements and syntax. Languages based on other parsers cannot evolve in that way. -- jeffrey On 02/25/2014 08:25 AM, Ruslan Shvedov wrote: Just caught myself thinking that :default ::= action = [name, values] :lexeme default ::= latm = 1 looks like a bit more consistent (well, for some definitions of consistency at least) syntax than the current :default ::= action = [name, values] lexeme default = latm = 1 :default ::= ... and :lexeme ~ ... are pseudo-rules, but lexeme default = ... is a statement. This is by design, so I'd appreciate any information from those in the know. -- 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 marpa-parser+unsubscr...@googlegroups.com. 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 marpa-parser+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: lexeme default vs. :default and :lexeme
Thanks for explaining. The thing was I thought if SLIF DSL could benefit from less diverse/more strict — (pseudo-)rule/adverbs only — syntax and model, where lexeme default statement becomes :lexeme default ::= pseudo rule inaccessible statement becomes an adverb of :default and/or :lexeme default pseudo-rules, e.g. :default action = [name, values] inaccessible = ok and named event statement — event ( 'name' | name ) = ( completed | nulled | predicted ) *symbol* — becomes an adverb of the rule whose LHS *symbol* is, e.g. event subtext = completed subtext event 'A[]' = nulled A event '^a' = predicted A become subtext ::= ... event completed = subtext A ::= ... event nulled = 'A[]' A ::= ... event predicted = '^a' Heretic as it is, but I thought I'd better braindump it. :) What do you think? On Tue, Feb 25, 2014 at 8:11 PM, Jeffrey Kegler jeffreykeg...@jeffreykegler.com wrote: The logic goes like this. Note the = instead of ::=. This signals that the statement is not a rule, and is non-lexical -- it's location in the file does not matter. Since it's not a rule, it does not take the form LHS ::= RHS2 ... The initial colon was for pseudo-symbols. Since the lexeme default statement is not a rule, it does not have a LHS, so what appears before the equal sign (=) is not considered symbol, pseudo- or otherwise. I am, frankly, less than 100% happy with this logic and my design choices, but there they are. In an ironic way, it does show Marpa's strength. Because it allows and exploits ambiguity, I can unpaint myself out of the corner, by introducing new statements and syntax. Languages based on other parsers cannot evolve in that way. -- jeffrey On 02/25/2014 08:25 AM, Ruslan Shvedov wrote: Just caught myself thinking that :default ::= action = [name, values] :lexeme default ::= latm = 1 looks like a bit more consistent (well, for some definitions of consistency at least) syntax than the current :default ::= action = [name, values] lexeme default = latm = 1 :default ::= ... and :lexeme ~ ... are pseudo-rules, but lexeme default = ... is a statement. This is by design, so I'd appreciate any information from those in the know. -- 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 marpa-parser+unsubscr...@googlegroups.com. 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 marpa-parser+unsubscr...@googlegroups.com. 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 marpa-parser+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Just uploaded a release candidate to CPAN: Marpa-R2 2.081_001
Here is a gist showing how to inspect Marpa grammarhttps://gist.github.com/9217513.gittogether with the new rule_name() and start_symbol_id() methods. Great release candidate -; Le lundi 24 février 2014 18:55:10 UTC+1, Jeffrey Kegler a écrit : I've just uploaded Marpa-R2 2.081_001https://metacpan.org/release/JKEGL/Marpa-R2-2.081_001, which is a release candidate. Value added includes: - - In the semantics, new array descriptor elementshttps://metacpan.org/pod/release/JKEGL/Marpa-R2-2.081_001/pod/Semantics.pod#Array-descriptor-actions: name, symbol, lhs. - The ability to change the treatment of inaccessibble symbolshttps://metacpan.org/pod/release/JKEGL/Marpa-R2-2.081_001/pod/Scanless/DSL.pod#Inaccessible-symbol-statement. (Inaccessible symbols are those which cannot be reached from the start symbol). - The SLIF's use of ambiiguity in its own DSL is now documentedhttps://metacpan.org/pod/release/JKEGL/Marpa-R2-2.081_001/pod/Scanless/DSL.pod#Ambiguity . - Rules can now be named, using the name adverbhttps://metacpan.org/pod/release/JKEGL/Marpa-R2-2.081_001/pod/Scanless/DSL.pod#name . Since this is a release candidate, testing is especially appreciated. Thanks, jeffrey -- 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 marpa-parser+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Just uploaded a release candidate to CPAN: Marpa-R2 2.081_001
Here is a gist showing how to inspect Marpa grammarhttps://gist.github.com/jddurand/9217513 together with the new rule_name() and start_symbol_id() methods. Great release candidate -; Le lundi 24 février 2014 18:55:10 UTC+1, Jeffrey Kegler a écrit : I've just uploaded Marpa-R2 2.081_001https://metacpan.org/release/JKEGL/Marpa-R2-2.081_001, which is a release candidate. Value added includes: - - In the semantics, new array descriptor elementshttps://metacpan.org/pod/release/JKEGL/Marpa-R2-2.081_001/pod/Semantics.pod#Array-descriptor-actions: name, symbol, lhs. - The ability to change the treatment of inaccessibble symbolshttps://metacpan.org/pod/release/JKEGL/Marpa-R2-2.081_001/pod/Scanless/DSL.pod#Inaccessible-symbol-statement. (Inaccessible symbols are those which cannot be reached from the start symbol). - The SLIF's use of ambiiguity in its own DSL is now documentedhttps://metacpan.org/pod/release/JKEGL/Marpa-R2-2.081_001/pod/Scanless/DSL.pod#Ambiguity . - Rules can now be named, using the name adverbhttps://metacpan.org/pod/release/JKEGL/Marpa-R2-2.081_001/pod/Scanless/DSL.pod#name . Since this is a release candidate, testing is especially appreciated. Thanks, jeffrey -- 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 marpa-parser+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Just uploaded a release candidate to CPAN: Marpa-R2 2.081_001
Thanx! Also, I added a comment because I get the output in a different order. -- 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 marpa-parser+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
