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 except probably with event completed statements which will read() the included file contents. My suggestion would be to process #includes by reading the inc files' contents into the main program's text and then just like c preprocessor does. So, #include's would need a separate grammar/recognizer.
To make a long story short, if you think the language needs a preprocessor, write a preprocessor (or just use cpp <https://www.cs.tut.fi/~jkorpela/html/cpre.html>). Not that Marpa can't do preprocessing (it probably can, as I said, with *event completed*), but a separate preprocessor just looks like a better design to me. *Math* — don't really know how much is the below a problem or if at all, but here goes: I can't see a rule for free (unbound) variables (*FV* *(·)*) and (·,·) in the grammar. LE/le seem to include both < and <=, while the paper has only <. 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. e.g. (Slide 25 in http://ashishagarwal.org/wp-content/uploads/2011/10/POPL2012_PDF_Theory_Presentation.pdf ) in var z ∼ flip (1/2) in var x1 ∼ uniform 1 2 in var x2 ∼ uniform 3 5 in return (if z then x1 else x2) out: f(x) = (1/2) ∗ <1 ≤ x ≤ 2> + (1/2) ∗ <3 ≤ x ≤ 5> ∗ (1/2) *Grammar* I'd humbly suggest streamlining the rules for expressions based on the primary ops list in the paper (not sure about (·,·) and its precedence), e.g. (very roughly, be gentle): Expression ::= Literal | Variable | Tuple || Finction Expression | Expression '<' Expression | Expression '<=' Expression | Expression '=' Expression || '(' Expression ')' | Expression '**' Expression || Expression '*' Expression | Expression '/' Expression || Expression '+' Expression | Expression '-' Expression Function ::= Builtin | UDF Builtin ::= neg | inv | (·,·) | fst | snd | exp | log | sin | cos| tan | <R of Z> Hope this helps, rns On Thu, Jul 17, 2014 at 5:58 PM, Paul Bennett <paul.w.benn...@gmail.com> 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 above paper well > enough to know whether I'm actually on the right track with the > language spec (but I am working on it). It's a bit vague and airy in > the paper itself, and I'm trying to tie it down to something actually > implementable. I've also taken the liberty of allowing *NIX style > shebang lines and C style #include lines, as a convenience to any > future users of the language. > > Anyway ... any opinions on what I might be doing wrong (or right), at > this early stage in the game? > > Thanks, > > > -- > P/PW/PWBENNETT > > -- > You received this message because you are subscribed to the Google Groups > "marpa parser" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to marpa-parser+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "marpa parser" group. To unsubscribe from this group and stop receiving emails from it, send an email to marpa-parser+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
