Hi Paul, here are my 2cents on this, in no particular order
*C style #include's* — aren't they supposed to be processed before parsing
the program? The grammar has actions for include's, but I honestly can't
see how you are going to inject the included file's contents at the
recongition time
In the paper's if X then Y else Z, X seems to be a (bound) variable (not
sure if/how they convert it to boolean, perhaps by whether it has PDF or
not), while it is a comparison in the grammar.
The name comparison is just a notational thing for my convenience.
Oh, but yes. Yes, indeed.
On 2014-07-17 at 10:58:04 -0400, Paul Bennett wrote:
Hi all,
I've started working here https://gist.github.com/PWBENNETT/8435996 on
a practical grammar for the language described here
http://ashishagarwal.org/2011/10/04/pdf-type-theory/
Trouble is, I don't (yet) understand the math in the
On Sun, Jul 20, 2014 at 9:56 PM, Paul Bennett paul.w.benn...@gmail.com
wrote:
On Sun, Jul 20, 2014 at 10:06 AM, Ruslan Shvedov
ruslan.shve...@gmail.com wrote:
Hi Paul, here are my 2cents on this, in no particular order
C style #include's — aren't they supposed to be processed before
A couple of nits on the updated grammar:
*1*
Expression ::= Value
and, later,
Value:
...
| Expression action = eval
...
This alternative looks redundant.
*2*
UDFExpr ::= UDF OptionalExpressionSequence
ExpressionSequence ::= Expression OptionalExpressionSequence
