[net.lang.pascal] X3J11

alexc@dartvax.UUCP (Alex Colvin) (08/28/84)

Personally, I find the new PASCAL standard on loop  variables  an
improvement.  I had been disappointed on reading J&W.

Perhaps because of Algol68  influence,  I  prefer  to  use  local
scalers  not  used elsewhere as loop variables.  I'm likely to be
embarrassed by finding some old program of  mine  broken,  but  I
think  I'd  consider this an improvement, like the discovery of a
long-hidden subscript bug.

Now... when is the committee going  to  do  something  about  the
statement  in J&W Ch.11, p. 71 (at least in the 1974 edition) re-
quiring that actual variable parameters be "distinct" (undefined,
but  presumably  meaning "not overlapping")?  This appears in the
User's Manual section, but not the Report.

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.

rcd@opus.UUCP (Dick Dunn) (09/07/84)

> 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.