[fpc-pascal] More syntax questions (part 3)

[Michael Van Canneyt]

On Sun, 24 Dec 2023, Adriaan van Os via fpc-pascal wrote:

> Michael Van Canneyt via fpc-pascal wrote:
>
>> I added univ and documented it.
>
> Something seems to have gone wrong with the <param-type> defintion on page 
> 212.

Corrected, thanks.

>
>>> Having a better look, the <parameter-declaration> rule defines just one 
>>> parameter. So, we get instead
>>>
>>>     formal-parameter-list = "(" [ parameter-declaration { ";" 
>>> parameter-declaration } ] [ "..." ] ")" .
>>>     parameter-list = formal-parameter-list .
>>> 
>>> comprising also the "ellipsis" parameter, which, according to Appendix D.6 
>>> of the Programmer's Manual is functionally equal to the varargs
>>> keyword.
>> 
>> Added to the diagrams.
>> 
>> I changed the diagram to be more clear (hopefully).
>
> But the rule for <formal-parameter-list> on page 211 now suggests that  "..." 
> can be used in the middle of the other declarations, which is not true.

I am aware of this. It is mentioned in the text, see below why this is so.


>
> 	formal-parameter-list = "(" [ parameter-declaration { ";" 
> parameter-declaration } ] [ "..." ] ")" .

This is not correct either, as it suggests that ( ... ) is correct. 
It is not, if you use ... there must be other arguments present.
You're also missing the ";" in front of the "...".

Likewise using parameter-declaration is not really correct, as it suggests that
parameters with default values can appear on any location in the list.
That is not correct, they must be the last parameters and cannot be followed
by a parameter without default value.

Likewise, "array of const" with a "cdecl" call-modifier can only appear as last
element in the list (it is translated to varargs). This is another
limitation. There are some limitations for possible combinations.

In short: To make a EBNF grammar which is 100% correct is not so simple and
will make the scheme extremely difficult to understand for a reader.

So I prefer to present a simpler version, and mention some limitations only in the
text:

That ... must be the last parameter is just one of them.

>
>>> Can't a variable also be qualified ? Therefore ?
>>>
>>>     variable-reference = qualified-identifier .
>> 
>> Yes.
>
> I didn't see a rule for <variable-reference> yet in the Language Reference.

I added it.

>
>>> 
>>> But to parse that, the rules for <interface-part> and <declaration-part> 
>>> need something like an <operator-declaration-part>, don't they ?
>> 
>> Yes, I had come to this conclusion myself, and I added it.
>
> I can't find the change yet.

That should be fixed now.

Michael.