More questions about the FreePascal Language Reference (version 3.2.0) part 3

26. Am I correct to assume the following equivalents for rules that I couldn't find a definiton for:

	formal-parameter-list                  = parameter-declaration .
	parameter-list                         = parameter-declaration .
	hint-directives                        = { hint-directive } .
	hint-modifiers                         = call-modifiers .
	hintdirective                          = hint-directive .
	hintdirectives                         = hint-directives .
	integer                               := [ sign ] unsigned-integer .
	integer-constant                      := integer .
	integerconstant                       := integer-constant .
	typed-declaration                      = type-declaration .

27. Section 13.2 defines a rule for <structured-statement> refering to a rule <exception-statement>

structured-statement = compound-statement | conditional-statement | repetitive-statement | with-statement | exception-statement .

Am I correct to assume ?

exception-statement = try-except-statement | try-finally-statement .

where

try-except-statement = "try" statement-list "except" exceptionhandlers "END" . try-finally-statement = "try" statement-list "finally" finally-statements "END" .

28. The documentation for macpas "UNIV" is missing ?

29. Am I correct to assume ?

ordinal-type = ordinal-type-identifier .
ordinal-type-identifier = identifier .

30. Am I correct to assume that <desctuctor-header> was meant to be <destructor-header> ?

31. Are the operators "<<" and ">>" missing in the syntax diagrams ?

32. Are the set operators "include", "exclude" missing in the syntax diagrams ? Is "><" missing (specifically) as set operator in the syntax diagrams ?

33. Section 12.1 gives "sign" in boldface in the rule for <factor>, suggesting that it is a keyword. Is that correct ?

(to be continued)

Yes, although integer-constant, integerconstant and integer should simply all be the same. I will correct that.

Yes.

Yes.

28. The documentation for macpas "UNIV" is missing ?

I have no idea what this is ?

Yes.

30. Am I correct to assume that <desctuctor-header> was meant to be <destructor-header> ?

Yes.

31. Are the operators "<<" and ">>" missing in the syntax diagrams ?

Yes and no.

I preferred not to document these since they are in fact C operators which I think are a historical mistake.

32. Are the set operators "include", "exclude" missing in the syntax diagrams ? Is "><" missing (specifically) as set operator in the syntax diagrams ?

Include/Exclude are not operators. They are procedure calls.

To illustrate, the following fails to compile:
---
type
   TEnum = (one,two,three);
   TEnums = set of TEnum;
var a : TEnums;
begin
   a:=[];
   a:=Include(a,one);
end.
---
iu.pp(9,6) Error: Incompatible types: got "untyped" expected "TEnums"
iu.pp(10,4) Fatal: There were 1 errors compiling module, stopping

The missing >< is an oversight

33. Section 12.1 gives "sign" in boldface in the rule for <factor>, suggesting that it is a keyword. Is that correct ?

No.

It is not a keyword, but one of '+' or '-'.

Hm. Lot of corrections to do.. I'll be busy tonight :-)

Michael.

Hm. Lot of corrections to do.. I'll be busy tonight :-)

Are these grammars in GIT so others can help by submitting merge requests? That way you can spread the love :-)

Everything concerning FPC is in git :-)

https://gitlab.com/freepascal.org/fpc/documentation/-/tree/main/syntax?ref_type=heads

Michael.

Michael Van Canneyt wrote

> 28. The documentation for macpas "UNIV" is missing ? I have no idea what this is ?

UNIV is macpas specific (as mentioned in Appendix D.6 of the Programmer's Manual)

With UNIV,

... ":" [ "ARRAY" "OF" ] type-identifier ...

in the syntax diagrams, becomes

... ":" [ "ARRAY" "OF" | UNIV ] type-identifier ...

The modifier UNIV indicates that the actual parameter can be of any type that has the same byte-size as the formal parameter.

Example:

	procedure HDispose( var theHandle: univ Handle); .....

which saves a value-type-cast when calling HDispose with handles that are not (precisely) of type Handle.

Another use of UNIV is type-compatibility of procedural parameters. For example with

  function BinaryFind
         (     theValuePtr             : univ UnivPtr;
               theFirstIndex           : Int32;
               theLastIndex           : Int32;
      function SmallerThan
         (     theIndex                : Int32;
               theValuePtr             : univ UnivPtr): boolean;
      function EqualTo
         (     theIndex                : Int32;
               theValuePtr             : univ UnivPtr): boolean;
           var theFoundIndex           : Int32): boolean;

we can call BinaryFind as follows

       theFoundFlag := BinaryFind
         ( @theCmdID, 1, kCmdCount, CmdIDSmallerThan, CmdIDEqualTo,

where

  function CmdIDSmallerThan
         (     theIndex                : Int32;
               theValuePtr             : CmdIDPtr): boolean; .....

and

function CmdIDEqualTo

         (     theIndex                : Int32;
               theValuePtr             : CmdIDPtr): boolean; ...

because CmdIDPtr is through UNIV type-compatible with

theValuePtr : univ UnivPtr

Regards,

Adriaan van Os

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.

Regards,

Adriaan van Os

But this kind of procedural parameter doesn't seem to be included in the rule for <parameter-declaration>. it is allowed in macpas and iso modes.

ISO-7185 Pascal has

formal-parameter-list = "(" formal-parameter-section { ";" formal-parameter-section } ")" . formal-parameter-section = value-parameter-specification | variable-parameter-specification | procedural-parameter-specification | functional-parameter-specification | conformant-array-parameter-specification .
functional-parameter-specification = function-heading . procedural-parameter-specification = procedure-heading .

Regards,

Adriaan van Os

Section 12.8.5 says "Elements can be added or removed from the set with the Include or Exclude operators" and table 12.6 lists them as "Set operators". So, that is confusing (to me).

Can't a variable also be qualified ? Therefore ?

variable-reference = qualified-identifier .

Your reply puzzles me. I mean code like this

{$mode fpc}
unit Operators;
interface
   const
     ki : complex = ( re: 0.0; im: 1.0);
   operator + ( z1: complex; z2: complex) sum: complex;
   operator + ( d1: double;  z2: complex) sum: complex;
   operator + ( z1: complex; d2: double ) sum: complex;

etcetera

But to parse that, the rules for <interface-part> and <declaration-part> need something like an <operator-declaration-part>, don't they ?

Regards,

Adriaan van Os

That may not be correct after-all, because an <ordinal-type> e.g. indexes arrays

array-type = [ "PACKED" | "bitpacked" ] "ARRAY" [ "[" ordinal-type { "," ordinal-type } "]" ] "OF" type .

In ISO-7185 Pascal we have

array-type = "array" "[" index-type { "," index-type } "]" "of" component-type . index-type = ordinal-type .
ordinal-type = new-ordinal-type | ordinal-type-identifier . new-ordinal-type = enumerated-type | subrange-type . enumerated-type = "(" identifier-list ")" .
subrange-type = constant ".." constant .

And in the FreePascal Language Reference <subrange-type> seems not to be referenced by any other rule.

subrange-type = constant ".." constant .

I suggest to change <ordinal-type> to

ordinal-type = ordinal-type-identifier | subrange-type | enumerated-type .

Regards,

Adriaan van Os

Thank you, added to the docs.

Michael.

Added to the diagrams.

I changed the diagram to be more clear (hopefully).

Michael.

I added univ and documented it.

Michael.

Yes.

Your question puzzled me.

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.

The following zip file contains the updated documentation: http://downloads.freepascal.org/fpc/beta/3.2.4-rc1/docs/doc-pdf.zip

Besides correcting your remarks, I did a general overhaul:
- I changed the use of space character in syntactic elements to dash (-)
- Improved some diagrams.
- synchronized some syntactical elements.
- Tried to make sure every syntactical element has a definition.

Michael.

Sorry, but are you sure this is the right download for all mentioned changes ?

Regards,

Adriaan van Os

No, the git submodule was not yet up-to-date when I built the docs.

Should be OK now, I uploaded a new version.

Sorry about that, thanks for pointing it out !

Michael.

Michael Van Canneyt wrote

I added univ and documented it.

Something seems to have gone wrong with the <param-type> defintion on page 212.

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.

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

I didn't see a rule for <variable-reference> yet in the Language Reference.

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

Regards,

Adriaan van Os

Corrected, thanks.

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.

I added it.

That should be fixed now.

Michael.

Michael Van Canneyt wrote

This is not correct either, as it suggests that ( ... ) is correct. It is not, if you use ... there must be other arguments present.

That is offending the reader: "You are to stupid to be given complete information".

It misses the point that programmers must be taught to think precise, abstract, conceptually and logically. For the same reason, modern math teaching doesn't work. It tries to circumvent abstract thinking by showing pictures. But there is no alternative to learning to think in abstract concepts. The more stupid education becomes, the less their pupils do learn <https://www.tagesschau.de/inland/gesellschaft/pisa-studie-128.html>.

If the language has the complexity built-in, there is no alternative but to be honest about it.

You're also missing the ";" in front of the "...".

Thanks for pointing that out. I have added it.

Regards,

Adriaan van Os

That is a load of nonsense.

I agree that logical and correct thinking is a necessity. I agree that modern teaching misses the point entirely.

But even in classical schooling you don't start by teaching general relativity theory to first-year secondary school students either. You need to build it up.

There are simply so many exceptions and limitations that the 100% correct diagram would be incomprehensible and needlessly complicated if you tried to capture every aspect for the full 100%.

Michael.

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

...

There are simply so many exceptions and limitations that the 100% correct diagram would be incomprehensible and needlessly complicated if you tried to capture every aspect for the full 100%.

If the EBNF grammar is only a guide provided as documentation for a human reader then you might want that. But if the EBNF grammar is used to drive a parser then it needs to be fully complete, accurate, and machine readable (see below).

Anyway, I strive to make the syntax complete and correct. When it is ready, I can send it in to be added as an Appendix to the Language Reference manual. I have an ebfn-driven general (back-parsing) parser that already works for Oberon-0 end UCSD-Pascal. So, the ebnf can be tested.

Is your parser able to read and validate the EBNF grammar itself for syntax and correctness (i.e. the grammar is complete and consistent) ? Can your parser be used with the EBNF grammar to parse and validate Pascal code and report syntax problems?

Wayne Sherman via fpc-pascal schrieb am
Mo., 25. Dez. 2023, 15:46:

The grammar embedded in the documentation is just that: a guide. Though that doesn't mean that Michael isn't trying to fix as many of the points that Adriaan mentioned as reasonably possible, because there obviously have been mistakes and oversights.

Regards,
Sven