[fpc-devel] FPC Language Specification

J. Gareth Moreton gareth at moreton-family.com
Mon May 20 02:07:15 CEST 2019


So after my argument and the counterarguments regarding the new case 
block warnings, I'm starting to wonder if a semi-official specification 
should be written for FPC's dialect of Pascal, much like ISO 7185 for 
Extended Pascal.  While FPC is probably the only tool that will use this 
dialect, it would be useful as a future reference guide as well as for 
conformance testing.

It might also aid in third-party documentation and enforcing coding 
standards so that all developers who use Free Pascal know what to expect 
from the language.  Case in point, I never knew that, strictly speaking, 
case blocks that didn't cover all possible inputs required an else 
branch even if it was empty - given the code compiled fine without it 
and its absence logically indicated that such a branch wasn't required, 
there was nothing to say that I was in conflict with some Pascal 
standards and getting an accusation of being a lazy programmer.  In this 
case, I fell back to a paradigm of being concise and straightforward, 
not adding unnecessary code such as, for example, constructors that do 
nothing but call the inherited version with no changes to the parameter 
list.

Back on topic though, as well as leaving no doubt as to how the language 
behaves, it might also work as a design specification to an extent.  For 
example, I still intend to program in support for pure functions, but 
beyond the *pure* directive (assuming all functions are pure until 
proven otherwise will cause too much of a performance penalty on the 
compiler) and the basic concept of their results being computed at 
compile time if possible, there isn't much else set in stone like where 
a pure function can be called (e.g. as part of a constant definition), 
what happens if the compiler determines that a pure function is actually 
impure, and what makes a function impure.  Having something like this 
fully decided and agreed upon in a language specification will ensure 
there are no disagreements with implementation specifics.

Long story short, having a specification with statements like "/Case 
blocks must have a valid branch for all possible input values, either 
through branches for individual values and ranges, or via an 
//*else*//branch.  Not abiding by this condition will raise a compiler 
warning./" and "/An "Unreachable code" warning shall be thrown if a case 
block contains an else branch but which already covers the entire input 
domain via other branches./" will go a long way to ensure the language 
stays conformant and tidy, I feel.

While there is documentation online that can easily explain all of this, 
I find it's only truly useful if you are looking up details on a 
specific feature - for example, the standard of expanding intermediate 
expressions to the CPU word size has caught many programmers off-guard.  
Having it in a single specification means that the curious can read 
through it in its entirety to learn of these nuances before falling foul 
of them.

What are your thoughts?

Gareth aka. Kit

P.S. I'm aware that writing it will be a mammoth task, especially to 
make it semi-official in its wording.  I have done paid proofreading 
work before so I can ensure that what I write is acceptable English, but 
it would need many sets of eyes evaluating it.



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20190520/bffbf38d/attachment.html>


More information about the fpc-devel mailing list