Re: Yet another ambitious project

[Ruslan Shvedov]

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
OptionalExpressionSequence ::= ExpressionSequence
 | Nothing

you probably know better, but why not just

UDFExpr ::= UDF Expression


just like FuncExpr?

Hope this helps,
rns



On Mon, Jul 21, 2014 at 12:26 AM, Paul Bennett 
wrote:

> >> 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. Variables are not allowed in the "X" slot in
> > my version. I'll have a think about that, and update the gist again
> > later.
>
> Okay. I've had more of a think, not just about the grammar but also
> about practical ways to implement the language. I may have strayed
> beyond the letter of the spec, but I suspect I've stayed within its
> spirit.
>
> URL as always is https://gist.github.com/PWBENNETT/8435996
>
>
> 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.

Re: Yet another ambitious project

[Ruslan Shvedov]

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 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.
>
> An #include is "just another macro". I was thinking of doing almost
> exactly as you say: spawning a second recce and using that to inject
> into the main symbol table (accomplished by the "our $self = bless { }
> => __PACKAGE__ ; sub new { return $self } ; ..." trick, where $self
> holds (among other things) the symbol table).
>
> I've updated the gist https://gist.github.com/PWBENNETT/8435996 to
> rename "Definition" to "Macro", and to allow an #include anywhere a
> Macro is allowed, to hopefully better explain my intentions (that is,
> until I actually have some "real" code to show).
>
> > To make a long story short, if you think the language needs a
> preprocessor,
> > write a preprocessor (or just use cpp).
>
> Maybe. It's certainly a good idea. I don't know whether I want to have
> the full capability for users to shoot themselves in the foot that cpp
> might provide, but there's definitely a good case to be made for it.
>
> > I can't see a rule for free (unbound) variables (FV (·)) and (·,·) in the
> > grammar.
>
> Syntactically I see no difference between bound and free variables
> that can't be made by context.
>
Yes, all the more that examples seem to contain no free variables.

Isn't (·,·) just the notation for what I've called a Tuple in my grammar?
>
Sure, missed that one, sorry.


> > LE/le seem to include both < and <=, while the paper has only <.
>
> The paper has, as you quote below, both < and ≤, which is incorporated
> into the (revised) gist as syntactic sugar for (or sugared by?) <= (or
> ⩽)
>
Yes (only < among the primeops though), but you're certainly right about
sugaring.

>
> > 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. Variables are not allowed in the "X" slot in
> my version. I'll have a think about that, and update the gist again
> later.
>
> Thanks for the input,
>
>
> --
> 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.

Re: Yet another ambitious project

[Zakariyya Mughal]

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 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.

Hi,

I was a bit confused as to the purpose of this DSL when you first posted
the paper back in January. Reading over it again, it looks like it would
be useful for specifying Bayesian networks. Looking up the algebra of
random variables and how random variables can be implemented in a
computer algebra system might help with the semantics of the language.
I don't know that much about measure theory, but I think can help with
writing some tests for this DSL.

Cheers,
- zaki

> 
> 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.

Re: Yet another ambitious project

[Paul Bennett]

>> 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. Variables are not allowed in the "X" slot in
> my version. I'll have a think about that, and update the gist again
> later.

Okay. I've had more of a think, not just about the grammar but also
about practical ways to implement the language. I may have strayed
beyond the letter of the spec, but I suspect I've stayed within its
spirit.

URL as always is https://gist.github.com/PWBENNETT/8435996


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.

Re: Yet another ambitious project

[Paul Bennett]

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 inject the included file's contents at the recongition time
> except probably with event completed statements which will read() the
> included file contents.

An #include is "just another macro". I was thinking of doing almost
exactly as you say: spawning a second recce and using that to inject
into the main symbol table (accomplished by the "our $self = bless { }
=> __PACKAGE__ ; sub new { return $self } ; ..." trick, where $self
holds (among other things) the symbol table).

I've updated the gist https://gist.github.com/PWBENNETT/8435996 to
rename "Definition" to "Macro", and to allow an #include anywhere a
Macro is allowed, to hopefully better explain my intentions (that is,
until I actually have some "real" code to show).

> To make a long story short, if you think the language needs a preprocessor,
> write a preprocessor (or just use cpp).

Maybe. It's certainly a good idea. I don't know whether I want to have
the full capability for users to shoot themselves in the foot that cpp
might provide, but there's definitely a good case to be made for it.

> I can't see a rule for free (unbound) variables (FV (·)) and (·,·) in the
> grammar.

Syntactically I see no difference between bound and free variables
that can't be made by context.

Isn't (·,·) just the notation for what I've called a Tuple in my grammar?

> LE/le seem to include both < and <=, while the paper has only <.

The paper has, as you quote below, both < and ≤, which is incorporated
into the (revised) gist as syntactic sugar for (or sugared by?) <= (or
⩽)

> 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. Variables are not allowed in the "X" slot in
my version. I'll have a think about that, and update the gist again
later.

Thanks for the input,


--
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.

Re: Yet another ambitious project

[Ruslan Shvedov]

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
). 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 | 

Hope this helps,
rns



On Thu, Jul 17, 2014 at 5:58 PM, 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 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.