On 20/05/2019 09:44, Michael Van Canneyt wrote:
On Mon, 20 May 2019, J. Gareth Moreton wrote:
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?
Maybe start from the official ISO pascal or extended pascal specs and
rewrite that to match the compiler implementation.
Michael.
Normally it doesn't quite work that way. It's more about what we expect
and desire the language to do from a design perspective - it is allowed
to change with implementation considerations, but normally it's not the
first point of consideration. To give the example of case blocks, since
that's been a point of contention lately, do we specify that all
possible input values have a valid branch and enumerated inputs aren't
range-checked, or do we just go by the implementation and say "it's not
a bug, it's a feature" if something looks different? There's also the
point that we may desire the language to behave a certain way, but a
subtle bug in the implementation means that it doesn't under certain
circumstances?
I suppose going by the implementation is better than nothing, but
normally it's not taken to be the definitive authoritive guide.
And for new features like *pure* functions, I much rather have something
written down and locked before I blindly start programming them and
making it up as I go along.
Gareth aka. Kit
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
