Symbol name can be any Perl string literal?

38 views
Skip to first unread message

rns

unread,
Nov 3, 2012, 3:55:27 PM11/3/12
to marpa-...@googlegroups.com
Just thought that subj could become like a killer feature of Marpa as with use utf8; (UTF-8 source encoding) it allows using mathematical (or any other, for that matter) notation in a textual grammar and that grammar, being properly parsed and evaluated, would be transformed into perl (Lingua::Romana::Perligata on steroids). 

Perl6 has malleable syntax with its regexes, but (as of yet) has no Marpa to ensure that everything you can write in BNF is parseable.

Weird as it is, just a thought.

Jeffrey Kegler

unread,
Nov 4, 2012, 1:07:40 PM11/4/12
to marpa-...@googlegroups.com
rns's message below suggests (or states) a very interesting idea: use Unicode characters outside the basic Latin for Perl extensions.  This means that the resulting Perl script cannot be in Unicode, but that is typically just as well and could be worked around for special cases.

For example, you could add APL operators to Perl, using Marpa to parse the extended expressions and translating to Perl.

And a templating package could use the corner brackets to indicate material that should be translated by the templating layer.

-- jeffrey

Ron Savage

unread,
Nov 4, 2012, 6:40:13 PM11/4/12
to marpa-...@googlegroups.com
Hi

On 05/11/12 05:07, Jeffrey Kegler wrote:
> rns's message below suggests (or states) a very interesting idea: use
> Unicode characters outside the basic Latin for Perl extensions. This
> means that the resulting Perl script cannot be in Unicode, but that is
> typically just as well and could be worked around for special cases.
>
> For example, you could add APL operators to Perl, using Marpa to parse
> the extended expressions and translating to Perl.

APL? Shudder!

> And a templating package could use the corner brackets to indicate
> material that should be translated by the templating layer.

Hmmm. So to translate markdown/*.down to HTML/*.whatever we could have 1
package and a set of grammars?

> -- jeffrey
>
> rns wrote:
>> Just thought that subj could become like a killer feature of Marpa as
>> with use utf8; (UTF-8 source encoding) it allows using mathematical
>> (or any other, for that matter) notation in a textual grammar and that
>> grammar, being properly parsed and evaluated, would be transformed
>> into perl (Lingua::Romana::/Perligata/
>> <http://www.csse.monash.edu.au/%7Edamian/papers/HTML/Perligata.html>
>> on steroids).
>> Perl6 has malleable syntax with its regexes, but (as of yet) has no
>> Marpa to ensure that everything you can write in BNF is parseable.
>>
>> Weird as it is, just a thought.
>
>
>


--
Ron Savage
http://savage.net.au/
Ph: 0421 920 622

Paul Bennett

unread,
Nov 4, 2012, 6:50:28 PM11/4/12
to marpa-...@googlegroups.com


>> And a templating package could use the corner brackets to indicate
>> material that should be translated by the templating layer.
>
>
> Hmmm. So to translate markdown/*.down to HTML/*.whatever we could have 1 package and a set of grammars?
>

Wild idea, related to the killer-app question... Presumably one could take a Z Notation spec (or even the LaTeX source for one?) and generate Perl skeleton code from it.

--
Pb

Jeffrey Kegler

unread,
Nov 4, 2012, 7:13:23 PM11/4/12
to marpa-...@googlegroups.com
> Hmmm. So to translate markdown/*.down to HTML/*.whatever we could have
> 1 package and a set of grammars?

Another interesting idea. This is similar to what I've been blogging
about configurable HTML parsing, where a DSL describes an HTML parser,
and generates an HTML parser for that variant.

-- jeffrey

Paul Bennett

unread,
Nov 4, 2012, 7:53:33 PM11/4/12
to marpa-...@googlegroups.com

>>> And a templating package could use the corner brackets to indicate
>>> material that should be translated by the templating layer.
>>
>>
>> Hmmm. So to translate markdown/*.down to HTML/*.whatever we could have 1 package and a set of grammars?
>>

Ovid's _Corinna_ package attempts to be a translation module to convert between schema languages (XSD, RelaxNG, SQL, etc). I wager it could be also be done with one killer-app Marpa::R2 module and a bunch of 'reader' and 'writer' grammars.

Jeffrey Kegler

unread,
Nov 4, 2012, 8:22:58 PM11/4/12
to marpa-...@googlegroups.com
Practical general BNF parsing has a target-rich environment. -- jeffrey

rns

unread,
Nov 4, 2012, 11:39:55 PM11/4/12
to marpa-...@googlegroups.com
Emacs was built on lisp; I can only wonder what an editor built on a practical general BNF parser can do. Build Gödel machines with Marpa for fun and profit. :)

Ron Savage

unread,
Nov 5, 2012, 1:57:49 AM11/5/12
to marpa-...@googlegroups.com
Hi

I wonder if a new feature could be added to MarpaX::Simple::Rules which
would allow the output of 2 files:
o One containing the grammar to be included in the source of the code
using Marpa::XS::Grammar. Sort of a pre-compute of the pre-compute.

o The other containing a set of function skeletons, each one
corresponding to an action in the grammar. This code would be basically
N copies of:

# --------------------------------------------------
# This is a function, not a method.

sub digraph
{
my($stash, $t1, undef, $t2) = @_;

return $t1;

} # End of digraph.

The point of this is that I'm going (one day soonish) to start a project
with dozens if not more than a hundred actions. I could write this code
myself, but having it generated would be nice.

Ron Savage

unread,
Nov 5, 2012, 1:59:09 AM11/5/12
to marpa-...@googlegroups.com
Hi Paul
I can't see this on MetaCPAN. Do you have a link?

Jeffrey Kegler

unread,
Nov 5, 2012, 3:15:38 AM11/5/12
to marpa-...@googlegroups.com
This github repository looks like it. -- jeffrey

Peter Stuifzand

unread,
Nov 5, 2012, 5:51:49 AM11/5/12
to marpa-...@googlegroups.com
Hi Ron,

I guess you could also create a program that iterates through the datastructure that is returned by 'parse_rules'. The format is equal to the argument expected by the 'rules' argument of Marpa::XS::Grammar. I guess something like the following would work.

          my $rules = parse_rules(...);
for my $rule (@$rules) {
    print 'sub ' . $rule->{action} . " {\n";
    print "\tmy (\$stash, ";
    my $c = @{$rule->{rhs}};
    print join ', ', map { '$t' . $_ } (1 .. ($c-1));
    print ') = @_;'  . "\n";
    print "}\n";
}




--
Peter Stuifzand | peterstuifzand.nl | @pstuifzand

Ron Savage

unread,
Nov 5, 2012, 4:26:11 PM11/5/12
to marpa-...@googlegroups.com
Hi jeffrey

On 05/11/12 19:15, Jeffrey Kegler wrote:
> This github repository <https://github.com/Ovid/Corinna> looks like it.

Thanx. I found a reference to it in my collection of Interesting Modules:

http://blogs.perl.org/users/ovid/2011/04/2011-perl-qa-hackathon---day-2.html

Ron Savage

unread,
Nov 5, 2012, 4:55:21 PM11/5/12
to marpa-...@googlegroups.com
Hi Peter

On 05/11/12 21:51, Peter Stuifzand wrote:
> Hi Ron,
>
> I guess you could also create a program that iterates through the
> datastructure that is returned by 'parse_rules'. The format is equal to the
> argument expected by the 'rules' argument of Marpa::XS::Grammar. I guess
> something like the following would work.
>
> my $rules = parse_rules(...);
> for my $rule (@$rules) {
> print 'sub ' . $rule->{action} . " {\n";
> print "\tmy (\$stash, ";
> my $c = @{$rule->{rhs}};
> print join ', ', map { '$t' . $_ } (1 .. ($c-1));
> print ') = @_;' . "\n";
> print "}\n";
> }

Sure - But I was hoping to outsource the work! Hahahaha.

Peter Stuifzand

unread,
Nov 5, 2012, 5:03:55 PM11/5/12
to marpa-...@googlegroups.com
You almost did. I guess the code would work, just add some Makefiles and shell redirection.

Generating the rules code can be done with Data::Dumper, I used it in MarpaX::Parser::Marpa for that.

--
Peter Stuifzand | peterstuifzand.nl | @pstuifzand


Reply all
Reply to author
Forward
0 new messages