http://www.perlmonks.org?node_id=933692


in reply to Writing a Programming Language in Perl

BUK's suggestion is quite good. IIRC, it's a fun manuscript.

I've been meaning to suggest Marpa to you for awhile. While still marked experimental it should be excellent for this kind of thing. I've wanted to play with it myself for a long time but tuits being what they are...

Marpa would be used, I'd expect, to convert a language spec/grammar to Perl and then you could use any number of strategies to freeze the resulting code (in memory, file, some other specialized cache) until the original source changed, at which point it could be "recompiled." Doing it this way should afford an easy path for testing and building up a grammar piece by piece. If you don't write tests as you go, you will be sorry down the road. If you do write tests, you'll be able to breeze through wrong turns and accidentally introduced bugs with confidence.

  • Comment on Re: Writing a Programming Language in Perl

Replies are listed 'Best First'.
Re^2: Writing a Programming Language in Perl
by ikegami (Patriarch) on Oct 25, 2011 at 21:39 UTC

    Marpa - Parse any Language You Can Describe in BNF

    Hopefully, it can do a bit more than that, because associativity cannot be described in BNF.

      Definitely not my forte but from the outside it looks wonderful. I'd love to hear your impressions of it if you're inclined and have time to take it though some of its paces.

        In theory, it works in practice.

        At a glance, it seems to me it assumes a simplistic world. The world doesn't conform to BNF. That's why Perl regular expressions aren't actually regular. As I said above, associativity is an example of something BNF can't handle. In BNF, all three of the following are the equivalent:

        foo : foo bar foo # Left- and right-recursive foo : baz foo : foo bar baz # Left-recursive foo : baz foo : baz bar foo # Right-recursive foo : baz

        You might think one could deviate from BNF and declare the second form to be left-associative and the third form to be right-associative.

        However, (most?) parsers can only handle left-recursion or right-recursion, not both. That means one cannot support both the second and the third form, which means we're back to square one.

        You need special tools to handle associativity (like PRD's <leftop> and <rightop>) or more generically, the ability to pass down context (like PRD's subrule args). I have examples of both methods.

        The ability to pass down context is surely useful in other circumstances, too. It can help if you have ambiguities in your grammar. It can probably help with specialised error messages.

Re^2: Writing a Programming Language in Perl
by programmer99 (Novice) on Oct 25, 2011 at 20:36 UTC
    Ok, I have a few questions (if you don't mind). What do you mean by grammar? How will Marpa help me? Thanks.

      The grammar of a language defines its syntax. Parsers (e.g. Marpa) take a sequence of bytes, characters or tokens, check if it conforms to the grammar, and assigns meaning to the components of the sequence as per the grammar.

      For example, the job of the parser is to receive "a+b*c" and return "a multiplication of ( an addition of ( identifier a ) and (identifier b ) ) and ( identifier c )".

        I am extremely greatful of the info that has been givenfrom everyone, really I am. But how does Marpa help me create a language/compiler in Perl?

      As I say, tuits in the round are the issue and without the time to cook up some working example I'd just be glossing the various documentation and BNF/ParseRec stuffage. I think a simple example can be cooked up but it's also not entirely trivial or my forte (hint, hint to others who might have something to show). This is quite interesting and I've been waiting to try some Marpa though. If I can grab an hour tonight I'll revisit this otherwise, the weekend, otherwise... uh, what were we talking about?