pacc logo

New-rep details

I'm starting to implement what I'm calling “new-rep”. To begin with, we can gloss over the details of exactly how it will be expressed in pacc, but we will need to decide how it will look in the AST. My first test case will be the unary counting grammar, which might look a bit like this:

S ← "x" { 0 } ("y" { a + 1 })* "x" → a

And in the AST, looks like this:

grammar 114: (null)
  preamble 113: (null)
  rule 112: S
    type 111: int
    seq 110:
      lit 109: x
      rep 108: (null)
        expr 107: 0
        seq 106:
          lit 105: y
          expr 104: a+1
            ident 103: a
      lit 102: x
      expr 101: a
        ident 100: a

However, there is already a major snag. What is the type of a? Obviously it will often, as this case, be the same as the enclosing rule, but in general it need not be. I suppose it might be possible to add a type-annotation in there somewhere; perhaps the base case could be { 0 :: int }, but that's not exactly appealing. The obvious thing to do is to say that a new-rep must always be a complete rule. That may make the syntax more appealing too. Let's see what our examples might look like:

S ← "x" u:Unary "x" → u
Unary ← { 0 } ("y" { a + 1 })*

In this case, the value of the new-rep rule defaults to the final value of the accumulator, although we may need an explicit → a for the time being. Or how about this?:

Unary* ← { 0 } "y" { a + 1 }

This is rather appealing. In the earlier examples, I've felt that the all-important repetition operator has got a bit lost. What about that tricky sum example? I actually sketched that out yesterday and rejected it, but hadn't thought about types at that stage. And the decimal example is already a single rule.

Another advantage of restricting new-reps to separate rules is that we don't have to worry about them nesting, which would present problems with the binding of a. Well, perhaps not. Clearly a rep-rule can call another one, and we'll have to keep things straight.

Last updated: 2015-05-24 19:45:29 UTC


Porting and packaging

One thing pacc needs is more users. And, perhaps, one way to get more users is to reduce the friction in getting started with pacc. An obvious lubricant is packaging. Read More...

Release relief

Looking at _pacc_coords(), I noticed that it seemed to have the same realloc() bug that I'd just fixed in _pacc_result(). However, the "list of arrays" trick really wasn't going to work here. Read More...

See more news articles