<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 20/05/2019 09:44, Michael Van
      Canneyt wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:alpine.DEB.2.20.1905201043170.9724@home.telenet.be">
      <br>
      <br>
      On Mon, 20 May 2019, J. Gareth Moreton wrote:
      <br>
      <br>
      <blockquote type="cite">
        <br>
        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.
        <br>
        <br>
        What are your thoughts?
        <br>
      </blockquote>
      <br>
      Maybe start from the official ISO pascal or extended pascal specs
      and
      <br>
      rewrite that to match the compiler implementation.
      <br>
      <br>
      Michael.
    </blockquote>
    <p>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?</p>
    <p>I suppose going by the implementation is better than nothing, but
      normally it's not taken to be the definitive authoritive guide.</p>
    <p>And for new features like <b>pure</b> functions, I much rather
      have something written down and locked before I blindly start
      programming them and making it up as I go along.</p>
    <p>Gareth aka. Kit<br>
    </p>
  <div id="DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2"><br />
<table style="border-top: 1px solid #D3D4DE;">
        <tr>
        <td style="width: 55px; padding-top: 13px;"><a href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient" target="_blank"><img src="https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif" alt="" width="46" height="29" style="width: 46px; height: 29px;" /></a></td>
                <td style="width: 470px; padding-top: 12px; color: #41424e; font-size: 13px; font-family: Arial, Helvetica, sans-serif; line-height: 18px;">Virus-free. <a href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient" target="_blank" style="color: #4453ea;">www.avast.com</a>
                </td>
        </tr>
</table><a href="#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1" height="1"> </a></div></body>
</html>