🚀 go-pugleaf

-------------
Just for the record, the ANSI/IEEE Joint Pascal Committee is X3J9. X3J11 is
the "C" committee.

Regarding the J&W User Manual suggestion that actual parameters passed to 'var'
formal parameters be "distinct", two points:

  First, the User Manual section was exactly that, not a definition of the
  language. As such, it includes style suggestions like this, which seems
  to be suggesting that "aliasing" of variables should be avoided.

  Second, such a restriction is not possible to enforce without examining
  the data flow of a program. Consider the following example:

    var
       x: integer;

    procedure twovars( var a, b: integer);
      begin
          { don't care }
      end;

    procedure sneaky( var p: integer);
      begin
        twovars( p, x);      { aliasing ! }
      end;

    begin
        sneaky( x);
    end;

  Here the passing of x as a var parameter to sneaky results in the call to
  twovars passing x as both actual parameters. It can certainly be argued that
  passing global variables as parameters opens the way for such aliasing, but
  I doubt anyone will seriously suggest prohibiting it. There are certainly
  programs that make use of passing (more) global variables as well as
  aliasing.

Regarding assignment to value parameters: This is practice that amounts
to style preference. I too have been bitten by forgeting to make a parameter
'var', but at the same time I have made use of such assignments. A value
parameter IS a local copy of the actual parameter. The best way to find this
problem (without changing the language and breaking a lot of existing programs)
is to either use a good cross-reference that shows assignments, or bug the
author of your compiler to (optionally!) provide a warning when a value
parameter is assigned a value.

                                              Bob Dietrich
                                              Tektronix, Inc.
                                              (503) 629-1727
{ucb or dec}vax!tektronix!robertd             uucp address
robertd@tektronix                             csnet address
robertd.tektronix@rand-relay                  arpa address

> Another feature that I try to avoid is assigning to value parame-
> ters.   It's  often  a  good  idea  to leave the original (actual
> parameter) value lying around, and make a local  copy  if  you're
> going  to  use  it as a local variable.  I guess that I wish that
> assignment to value parameters were an error.  I've been nailed a
> few times by forgetting the "var" in a procedure header.

It may be of interest that Pascal originally had "const" and "var"
parameters.  "Var" parameters worked as they do today.  "Const" parameters
behaved as if they'd been defined by a "const" declaration.  The change to
the current form happened in the "Revised Report" (which was fairly early
on compared to the real evolution and popularization of the language).  One
could speculate on the reason for the change--my guess is that it is
beneficial in the case where the value passed in requires some effort to
copy.  If the procedure needs scratch storage of the same type (size) as
the value passed in, and if that storage had to be allocated anyway to hold
the value, why not make the storage available?

Moreover, there's a philosophical point here:  I don't think that there's
anything inherently "bad" in using value parameter storage--just think of
it as an initialized local variable.  If the language provides a mechanism,
and it's a useful mechanism, and it's not "inherently evil" (big judgment
call there), why not use it?

I've been nailed once in a great while by forgetting the "var".  I wonder
if that isn't really more a problem with having a default?  That is,
suppose that the language had been designed so that you HAD to say either
"value" or "var" - then you'd be forced to think which you wanted and
wouldn't get caught by unexpected defaulting.
-- 
Dick Dunn	{hao,ucbvax,allegra}!nbires!rcd		(303)444-5710 x3086
   ...I'm not cynical - just experienced.