Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!sdd.hp.com!cs.utexas.edu!uunet!paralogics!shaw
From: shaw@paralogics.UUCP (Guy Shaw)
Newsgroups: comp.lang.perl
Subject: Re: How about a finicky printf()?
Summary: Not just finicky printf(), finicky arrays
Keywords: printf, format string, bounds checking
Message-ID: <431@paralogics.UUCP>
Date: 23 Jun 91 07:35:47 GMT
References: <430@paralogics.UUCP>
Organization: Paralogics; Santa Monica, CA
Lines: 80


How about finicky arrays?

In article <430@paralogics.UUCP>, I suggested that printf() should be more
strict about its arguments.

>        Extra arguments are ignored.  Arguments needed beyond the number
> given are silently supplied as though a null value were given.  So, the
> argument list is, in effect, padded with null values.

I do not believe that Perl goes to extra work to be so forgiving about
the arguments to printf().  Ignoring extra arguments is easy.  I think
it just doesn't bother to check that there are any extra arguments.
As for the padding of printf's argument list with null values, this
might take extra work in many languages, but in Perl, I think it is
just a natural consequence of the way Perl deals with out-of-bounds rvalue
array references, i.e. silently supply a null value.

So, come to think of it, I wouldn't mind having Perl complain about
out-of-bounds rvalue array refs.  But that brings up two problems.

Problem 1: strict enforcement of array bounds for rvalue array refs
would break existing code.  There is a lot of code out there like

        while($ARGV[0]) { ... shift; }

It wouldn't have been any problem for me to code these things slightly
differently if Perl were strict about array bounds.  But that is
probably part of *The Perl Way*, now.  So, even complaining only
when the -w option is on is no good.

Problem 2: consistency between ordinary array and associative array
semantics.  What about accessing an associative array with a key that
is not in that array?  Isn't that analogous to accessing an ordinary
array with a subscript that isn't in that array - yet?  Well, yes but
the way Perl uses a subscript-like notation for accessing associative
arrays comes form awk.  In an Algol/Pascal/C-like compiled language you
would have functions for accessing associative arrays which provide richer,
though more clumsy notation.  There is a lot more historical precedent
for bounds checking for ordinary arrays with subscript notation.

There has got to be a way of keeping the advantages of simple
subscripting notation and automatic extension of arrays on demand,
without worrying about the grubby low-level bookkeeping details, yet
still get the safety of bounds checking when you want it.

Having said all that ... there are times when I want automatic run-time
bounds checking and times when I do not.  And that may apply to access
of non-existent entries in associative arrays as well as to ordinary
arrays.  So, the behavior ought to be controllable for each array.
Make the default be the way arrays behave now.  Introduce a new perl
function, strict(), such that strict(@array) would make any out-of-bounds
rvalue references to that array cause an exception.  Since this is run-time
stuff, I suppose you could have unstrict(@array), also; but I would tend
to use strict() once up front as a sort of declaration, and would not want
to change the behavior of an array, back and forth.  I would have preferred
that arrays be strict by default, but there's that pesky existing code
problem again.

I would still want assignment to arrays to automatically extend
the array.  The array notation is just too convenient.  But if an array
is strict I think array extension should be restricted to adding on
immediately to the beginning or end without automatically creating
(or failing to complain about) null values for unmentioned subscripts.

Unless I am mistaken about the way Perl is implemented, especially
about the kind of information that is already carried around at run-time
about all arrays, then run-time setting of the strictness of bounds
checking of each array can be done without doing unnatural acts to the
Perl interpreter and without a significant performance penalty.

Afterthought: perhaps an out-of-bounds exception can generate a
pseudo-signal that can be caught.

Just Another Perl Nudge from
Just Another Perl Drudge
-- 
Guy Shaw
Paralogics
paralogics!shaw@uunet.uu.net  or  uunet!paralogics!shaw