<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>Hi,<br>
    </p>
    <div class="moz-cite-prefix">Στις 20/2/2019 3:36 μ.μ., ο Paul van
      Helden έγραψε:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAPjGFZcBpA2mUeRB8gATwjC4nhg_PWBH8cyB6aqWSfEEQBn8rQ@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <div dir="ltr">
          <div class="gmail_quote">
            <blockquote class="gmail_quote" style="margin:0px 0px 0px
              0.8ex;border-left:1px solid
              rgb(204,204,204);padding-left:1ex"><br>
              > > 1. it makes it easier to see the whole picture
              just looking at the loop<br>
              > > body, no need to scroll up; (The loop body might
              be just 10 lines of code,<br>
              > > whereas the whole containing function sometimes
              has 1000s)<br>
              > ><br>
              > > 2. it isoltates the scope of such variable(s),
              therefore preventing some<br>
              > > sorts of accidental misuse outside of e.g. the
              containing loop (which still<br>
              > > do happen to me ocasionally in Pascal).<br>
              ><br>
              > I've already tried to make these points, nobody seems
              to buy it.  IIRC<br>
              > Michael (vC) said that functions shouldn't be that
              long, so then it's<br>
              > not a problem (perhaps his world is perfect, but mine
              certainly isn't).<br>
              <br>
              Anyone can split a function in many others. It's not so
              difficult and,<br>
              actually, it should be done.<br>
              <br>
              > I'm mostly more interested in limiting the scope to
              prevent accidental<br>
              > use, like you.  It can also offer more fine grained
              control of where<br>
              > managed variables get freed.<br>
              <br>
              Try to see restrictions as a good thing.<br>
              In this case, which Pascal doesn't allow to declare inline
              variables,<br>
              you must split big functions, which has many local
              variables, in<br>
              others to have a better understanding of the algorithm. At
              the end,<br>
              you might have a better design and reuse of the code.
              Everybody wins:<br>
              you, your code, Pascal team - as they don't need to change
              the<br>
              compiler - and Niklaus Wirth might not throw a curse in
              us.<br>
              <br>
            </blockquote>
            <div><br>
            </div>
            <div>O dear, now I've dunnit... </div>
            <div><br>
            </div>
            <div>So the argument against is: (1) split your long
              functions, because you should; and (2) Wirth didn't do it,
              so good it is not.</div>
          </div>
        </div>
      </div>
    </blockquote>
    <p>  Even if declaring variables as close as possible to where the
      variable will be used ( debugging wise not readability wise )
      leads to more correct code, the problem is to avoid the temptation
      to use them in other places too. <br>
    </p>
    <p>  AFAIK, one of Pascal's primary design goals is to won't let you
      shoot yourself in the foot, and IMO that feature is not in that
      direction.<br>
    </p>
    <p>-- <br>
    </p>
    <p>Dimitrios Chr. Ioannidis<br>
    </p>
  </body>
</html>