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
OptionalExpressionSeque
On Sun, Jul 20, 2014 at 9:56 PM, Paul Bennett
wrote:
> On Sun, Jul 20, 2014 at 10:06 AM, Ruslan Shvedov
> 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 parsing
> the
> > program? The grammar has act
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 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, inde
On Sun, Jul 20, 2014 at 10:06 AM, Ruslan Shvedov
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 parsing the
> program? The grammar has actions for include's, but I honestly can't see how
> you are going to i
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 excep
