[SPAM] strict productions

John L. Ries jries at salford-systems.com
Wed Feb 15 21:20:45 CET 2017


I'm not at all sure we really want a trilingual compiler, but the parser
is complete or nearly so, it's probably worth a look.

--------------------------|
John L. Ries              |
Salford Systems           |
Phone: (619)543-8880 x107 |
or     (435)867-8885      |
--------------------------|


On Wed, 15 Feb 2017, Bastiaan Veelo wrote:

>
>       On 15 Feb 2017, at 18:10, Paul Isaacs
>       <paul at redpineinstruments.org> wrote:
> Interesting:
>
> function-access1 = record-function1.field1  => using
> function-access|record-function
> record-function1 = function-access2         => using record-function
> production
> function-access2 = record-function2.field2  => using
> function-access|record-function
> record-function2 = x( a )                   => using
> function-access|entire-function
>
> function-access2 = x( a ).field2            => reducing
> function-access2
> record-function1 = x( a ).field2            => reducing
> record-function1
> function-access1 = x( a ).field2.field1     => reducing
> function-access1
>
> x( a ).field2 compiles and executes
>
> x( a ).field2.field1 of course does not compile unless field1 is a
> field of field2.
>
>
> I can’t say I follow you exactly...
>
>       But is it a syntacticly correct result of these productions?
>       If so is it an ambiguity in the grammar? Do the productions have
>       precedence rules?
>       e.g. variable-access has higher precedence than function-access
>
>
> I wrote a recursive descent parser for Extended Pascal in the D language
> using the Pegged library, which takes the rules of the standard almost
> literally. I remember changing the order of options in some rules, but I am
> unsure whether that was for efficiency or for giving precedence to common
> constructs. I do remember seeing ambiguities in variable access and function
> access, which I imagine can be resolved by keeping a symbol table of earlier
> definitions.
>
> My parser is an interesting project but turned out to be rather inefficient
> at the moment. If there is an interest I will consider to put it online.
>
> Bastiaan.
>
>


More information about the Gpc mailing list