Hello,
Is the 10206 spec not strict?
6.8.6.2 Indexed-function-accesses
An indexed-function-access shall denote a component of the value of a function-access possessing an array-type or a string-type.
indexed-function-access = array-function `[' index-expression { `,' index-expression } `]' j string-function `[' index-expression `]' .
array-function = function-access .
But:
6.8.6 Function accesses
function-access = entire-function-access | component-function-access | substring-function-access .
component-function-access = indexed-function-access | record-function-access .
entire-function-access = function-designator .
And:
6.8.5 Function-designators
function-designator = function-name [ actual-parameter-list ]
According to the productions an indexed-function-access => array-function => function-access=>indexed-function -access
Therefore, the only exit is via entire-function-access. But this would lead to a sentence of the form:
x( a,b,c)[ 6,7,8 ] being valid and it is not.
From:
6.8.6.2 Indexed-function-accesses
An indexed-function-access shall denote a component of the value of a function-access possessing an array-type or a string-type.
But this would be an identifier and the function-access productions do not indicate identifiers.
Are the productions not strict? Does function-access include identifiers?
Regards,
Paul Isaacs
On 15 Feb 2017, at 08:10, Paul Isaacs paul@redpineinstruments.org wrote:
x( a,b,c)[ 6,7,8 ] being valid and it is not.
I think it is. This compiles and runs:
program array_return(output);
type i5 = integer value 5; arr_type = array[1..10, 1..10, 1..10] of i5;
var arr : arr_type; a, b, c : integer;
function x(a, b, c : integer) : arr_type; begin x := arr; end;
begin a := 2; b := 3; c := 4; writeln(x(a, b, c)[6, 7, 8]); {5} end.
On 15/02/17 03:06 AM, Bastiaan Veelo wrote:
On 15 Feb 2017, at 08:10, Paul Isaacs <paul@redpineinstruments.org mailto:paul@redpineinstruments.org> wrote:
x( a,b,c)[ 6,7,8 ] being valid and it is not.
I think it is. This compiles and runs:
Bastiaan,
Thanks! You're right. I'm finding it hard to go from the productions to code when the productions are recursive through intermediates.
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. 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
Regards,
Paul Isaacs
On 15 Feb 2017, at 18:10, Paul Isaacs paul@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.
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@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-accessI 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.
The parser is complete except the handling of ambiguities. But it is just that: a parser. The output is an AST.
I have meant to submit the grammar as an example to Pegged [1], I’ll see if I can find some time for that, together with an example parser.
Bastiaan.
[1] https://github.com/PhilippeSigaud/Pegged
On 15 Feb 2017, at 21:20, John L. Ries jries@salford-systems.com wrote:
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:
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.
The parser is online now as an example of Pegged:
https://github.com/PhilippeSigaud/Pegged/tree/master/pegged/examples/extende...
However, the "ordered choice” parsing in PEG is not a good solution to deal with the ambiguities in the Extended Pascal grammar. When I threw one of my Pascal sources at it, it just failed to parse. I will see if implementing a “longest match choice” makes a difference. https://github.com/PhilippeSigaud/Pegged/issues/218
Note that this project is not meant to be part of a robust traditional compiler. My interests are in transcompiling, and therefore I am not concerned with the quality of error messages or performance. Also, as I understand it, the gpc frontend already parses almost all of EP, so I am not at all sure that writing a new parser is worth while. But for me it is a nice subject to get acquainted with D and experience its powers.
Bastiaan.
On 16 Feb 2017, at 09:59, Bastiaan Veelo Bastiaan@Veelo.net wrote:
The parser is complete except the handling of ambiguities. But it is just that: a parser. The output is an AST.
I have meant to submit the grammar as an example to Pegged [1], I’ll see if I can find some time for that, together with an example parser.
Bastiaan.
[1] https://github.com/PhilippeSigaud/Pegged
On 15 Feb 2017, at 21:20, John L. Ries jries@salford-systems.com wrote:
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:
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.
Gpc mailing list Gpc@gnu.de https://www.g-n-u.de/mailman/listinfo/gpc
Just a follow-up. I have since added a longest match alternator to Pegged, and it now successfully parses all Extended Pascal source that I have tried (with few Prospero extensions). It is too slow though to be the basis for a compiler; at this point.
Let me know if anyone here wants to try, I can provide binaries. (The source is there of course, see below).
Bastiaan.
On 18 Feb 2017, at 11:37, Bastiaan Veelo Bastiaan@Veelo.net wrote:
The parser is online now as an example of Pegged:
https://github.com/PhilippeSigaud/Pegged/tree/master/pegged/examples/extende...
However, the "ordered choice” parsing in PEG is not a good solution to deal with the ambiguities in the Extended Pascal grammar. When I threw one of my Pascal sources at it, it just failed to parse. I will see if implementing a “longest match choice” makes a difference. https://github.com/PhilippeSigaud/Pegged/issues/218
Note that this project is not meant to be part of a robust traditional compiler. My interests are in transcompiling, and therefore I am not concerned with the quality of error messages or performance. Also, as I understand it, the gpc frontend already parses almost all of EP, so I am not at all sure that writing a new parser is worth while. But for me it is a nice subject to get acquainted with D and experience its powers.
Bastiaan.
On 16 Feb 2017, at 09:59, Bastiaan Veelo Bastiaan@Veelo.net wrote:
The parser is complete except the handling of ambiguities. But it is just that: a parser. The output is an AST.
I have meant to submit the grammar as an example to Pegged [1], I’ll see if I can find some time for that, together with an example parser.
Bastiaan.
[1] https://github.com/PhilippeSigaud/Pegged
On 15 Feb 2017, at 21:20, John L. Ries jries@salford-systems.com wrote:
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:
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.
Gpc mailing list Gpc@gnu.de https://www.g-n-u.de/mailman/listinfo/gpc
Gpc mailing list Gpc@gnu.de https://www.g-n-u.de/mailman/listinfo/gpc
I canât say I follow you exactly...
Hello Bastiaan,
Is the sentence a(x).field1.field2 a syntactically valid outcome of the function-access production?
1) function-access = component- function access 2) component-function-access = record-function-access
substituting 2) in 1) 3) function-access = record-function-access
4) record-function-access = record-function '.' field-specifier substituting 4) in 3)
5) function-access = record-function '.' field-specifier
6) record-function = function-access substituting 6) in 5)
7) function-access = function-access '.' field-specifier
which makes function-access left recursive.
Is 7) lexically valid but semantically invalid because function-access '.' field-specifier can not be a function-access?
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.
I am keeping a symbol table for that purpose.
I am staying away from compiler-compilers in order to make the parser more approachable and less abstract. It is recursive descent written in 10206 compliant pascal.
Regards,
Paul Isaacs
Hello Paul,
On 16 Feb 2017, at 02:49, Paul Isaacs paul@redpineinstruments.org wrote:
Is the sentence a(x).field1.field2 a syntactically valid outcome of the function-access production?
I think so, but the water is getting deeper.
- function-access = component- function access
- component-function-access = record-function-access
substituting 2) in 1) 3) function-access = record-function-access
- record-function-access = record-function '.' field-specifier
substituting 4) in 3)
function-access = record-function '.' field-specifier
record-function = function-access
substituting 6) in 5)
- function-access = function-access '.' field-specifier
which makes function-access left recursive.
Is 7) lexically valid but semantically invalid because function-access '.' field-specifier can not be a function-access?
I see. Interesting question.
I have not concerned myself with semantic analysis. My objective was to translate working EP code into D code, and recon that semantics (and ambiguity even) can be disregarded in that application.
Bastiaan.
On 16 Feb 2017, at 02:49, Paul Isaacs paul@redpineinstruments.org wrote:
I can’t say I follow you exactly...
Hello Bastiaan,
Is the sentence a(x).field1.field2 a syntactically valid outcome of the function-access production?
- function-access = component- function access
- component-function-access = record-function-access
substituting 2) in 1) 3) function-access = record-function-access
- record-function-access = record-function '.' field-specifier
substituting 4) in 3)
function-access = record-function '.' field-specifier
record-function = function-access
substituting 6) in 5)
- function-access = function-access '.' field-specifier
which makes function-access left recursive.
Is 7) lexically valid but semantically invalid because function-access '.' field-specifier can not be a function-access?
For what it’s worth, my parser fails to parse the following:
program isaacs;
begin a(x).field1.field2; end.
EP (failure) +-EP.BNVCompileUnit (failure) +-EP.Program (failure) +-EP.ProgramBlock (failure) +-EP.ProgramComponent (failure) +-EP.MainProgramDeclaration (failure) +-EP.ProgramHeading [0, 14]["program", "isaacs"] | +-EP.PROGRAM [0, 7]["program"] | +-EP.BNVProgramName [8, 14]["isaacs"] | +-EP.Identifier [8, 14]["isaacs"] | +-EP.BNVAnyIdentifier [8, 14]["isaacs"] +-EP.MainProgramBlock (failure) +-EP.Block (failure) +-EP.StatementPart (failure) +-EP.CompoundStatement (failure) +-EP._ [22, 27]["\n "] | +-EP.Spacing [22, 27]["\n "] +-EP.StatementSequence [27, 31]["a", "(", "x", ")"] | +-EP.Statement [27, 31]["a", "(", "x", ")"] | +-EP.SimpleStatement [27, 31]["a", "(", "x", ")"] | +-EP.ProcedureStatement [27, 31]["a", "(", "x", ")"] | +-EP.ProcedureName [27, 28]["a"] | | +-EP.ProcedureIdentifier [27, 28]["a"] | | +-EP.Identifier [27, 28]["a"] | | +-EP.BNVAnyIdentifier [27, 28]["a"] | +-EP.ActualParameterList [28, 31]["(", "x", ")"] | +-EP.ActualParameter [29, 30]["x"] | +-EP.Expression [29, 30]["x"] | +-EP.SimpleExpression [29, 30]["x"] | +-EP.Term [29, 30]["x"] | +-EP.Factor [29, 30]["x"] | +-EP.Primary [29, 30]["x"] | +-EP.FunctionAccess [29, 30]["x"] | +-EP.EntireFunctionAccess [29, 30]["x"] | +-EP.FunctionDesignator [29, 30]["x"] | +-EP.FunctionName [29, 30]["x"] | +-EP.FunctionIdentifier [29, 30]["x"] | +-EP.Identifier [29, 30]["x"] | +-EP.BNVAnyIdentifier [29, 30]["x"] +-discard!(EP.END) failure at line 3, col 8, after "n\n a(x)" expected ""end"", but got ".field1.fi"
-
Bastiaan Veelo -
John L. Ries -
Paul Isaacs