I am delighted to report that Richard Smith has been using pacc, giving me useful feedback, and asking awkward questions (which is great!).
I will write some documentation very soon about bindings, but one thing that came out of our discussion is that in n:Rule the type of n is the same as the type of Rule. In all other cases, n:(not a rule), the type of n is ref_t. I was rather surprised to discover that it is legal to write n:"foo".
So, awkward question coming up: what is the type of n in n:(Rule)? One could argue that parentheses are only used for grouping things (differently from the usual precedence) and therefore shouldn't change the type of anything. I suspect that this is how pacc currently interprets it, although I haven't peered at pacc.pacc or tested it yet.
On the other hand, since there's no reason to write redundant parentheses, we could make n:(Rule) mean that n has type ref_t, and is bound to whatever Rule matches. Another way to express this would be n:(Rule ε). This might occasionally be useful, so let's make it so.
That wasn't even trivial to implement: it was already what pacc does. (Honestly, I really did think about it and choose this option before trying it!) Peering at pacc.pacc, the parentheses rule looks unpromising:
Rule6 ← lParen r:Rule0 rParen → r
But Rule1 wraps a seq node around the call, and that's all we need to trigger the debind() code in sugar.c that will achieve what we wanted. There is a new test case to verify that this works as intended.
Last updated: 2015-05-24 19:45:30 UTC
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...
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...