Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 08:20 AM 8/4/00 -0400, John Tobey wrote:
> >Suppose we use the low 2 bits as a type marker, so 30-bit ints are
> >representable directly in the "SV*".
>
> Let's not--I really loathe that sort of thing, it can be a portability
> nightmare, and it's an internals thing anyway.
I, too, find it unsightly, but I wouldn't rule it out for all time
based on unsightliness alone. The technique is used in other
languages with apparent success.
> Don't sweat the internals for this. Figure out whether its a good or bad
> thing based on the language merits, not the internals issues.
Well, I hold that it is a good idea based on language merits, for the
reasons stated. I hope, too, that we language purists (*cough*) don't
completely lose sight of the interests of compilers.
Here's the complete RFC-or-whatever-they're-called:
=head1 TITLE
Elements of @_ should be read-only in unprototyped subs
=head1 VERSION
Maintainer: John Tobey <[EMAIL PROTECTED]>
Date: 4 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number:
=head1 ABSTRACT
Unprototyped subs should not be allowed to modify their callers' data
simply by assigning to elements of the arg array. The change would
not affect subs with a prototype, so the examples in
L<perlsub/Prototypes> would still work.
=head1 DESCRIPTION
Assignment to C<$_[0]>, etc., as a form of passing arguments by
reference is obsolete now that Perl has hard references and C<\$> in
prototypes. It may soon become even less useful as more powerful
prototyping is introduced. The feature is confusing, since it means
that the recommended convention for naming parameters (by assigning
C<@_> to a C<my> list) alters semantics.
Currently, values I<returned> from subs are non-assignable by default.
Making the same true of sub arguments adds consistency and reduces
surprise. To those familiar with a language like C, sub arguments
I<look> as though they are passed by value.
Prototyping is a way to override the default semantics. A prototype
says, "I know what I'm doing, let me have it my way." When
prototyping, the programmer assumes responsibility for (and, ideally,
finer control over) some aspects of optimization. This could give
greater opportunities in exchange for a little effort if, for example,
prototypes were allowed to specify pass-by-value or by-reference.
(C<\$> kind of does this, but not in an optimal way, as it uses a
Perl-level reference.)
The Perl 5 (and older) behavior precludes some optimizations based on
representing objects as more than simple pointers (e.g., two- or
three-word structures, or pointers with embedded bit fields). Also,
if we find a way to specify or infer argument types, a sub whose C
form looks like
SV* my_sub(SV*, SV*, SV*)
might be compiled as
IV my_sub(UV, NV, SV*)
but only if the first two args are semantically passed by value.
=head1 IMPLEMENTATION
A fascist implementation would emit a compile-time error any time
C<@_> or one of its elements were assigned to, taken a refernce to,
etc. A friendlier version would automatically copy the arg value to a
new temporary.
This change would mean a slight-to-moderate Perl 5 compatibility
breakage. The 5-to-6 converter could insert whatever trick is used to
obtain the Perl 5 behavior (perhaps a C<(@)> prototype or a pragma)
when it detects argument modification.
=head1 ISSUES
Maybe the prototype override isn't a good idea, and just a pragma
would do.
=head1 REFERENCES
L<perlsub>
