[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