This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
structures and interface definitions
=head1 VERSION
Maintainer: David Nicol <[EMAIL PROTECTED]>
Date: 8 Aug 2000
Last Modified: 5 Sep 2000
Mailing List: [EMAIL PROTECTED]
Version: 2
Number: 75
Status: Frozen
=head1 ABSTRACT
A structure definition language can also be used to provide
named arguments to subroutines, and vice versa.
=head1 SUMMARY
$xys = qs{ $x, my $y }; # $x is pass by reference, $y by value
sub foo($xys){
print "x is $x and y is $y\n";
};
%fasthash = unpack( $xys, $Structure );
$Structure = pack( $xys, %fasthash );
=head1 DESCRIPTION
Stack based compiled languages like C organize all the arguments
to a subroutine onto the stack before calling the subroutine, and
from the subroutine the arguments are accessed, in the compiled
machine code, with offsets from a "stack pointer."
This process is similar to the way that fields in a record are accessed
by a fixed offset from a pointer to the beginning of the record.
Perl has a structure definition syntax, it is the "pack format" language.
By extending that language in a way that names are associated with parts
of the format, we can achieve something that will interact with the
other language elements much like a hash.
We may also import structure definition languages from other languages
that have them, such as C or COBOL.
Imagine:
use COBOL_pic; # might not be needed
$mypic =<<ENDCOBOL;
I don't know COBOL data structure language :)
ENDCOBOL
%DataHash = unpack $mypic, $SomePackedCobolData;
A_routine_taking_the_data(%DataHash);
#Or, in a more perl5 way:
%{$DataHash} = unpack $mypic, $SomePackedCobolData;
bless $DataHash, 'coboldata';
operate $DataHash;
Pseudohash type definitions are Structure-Definitions are Interfaces. All of
these may be considered key-value associative arrays for purposes
of language syntax.
Structure definitions are declared using the C<qs> operator,
or can be inlined in situations that syntacticly call for them,
such as function prototypes.
In invoking a subroutine prototyped using a structure definition,
(aka fully defined interface) the arguments can come from
a list, in which case they are loaded into the structure in order,
they can come from a(nother) (pseudo)hash, in which case they are
loaded into the structure by name.
Rather than Special-casing the interpretation of
function call parameters, we can create an object of type $xy
and send it to the function that takes that type. This way
the name localization is in the called subroutine, and we
don't have names from subroutines appearing in the calling
code.
Any subroutine with a prototype with named variables, no matter how scoped,
can be called with a hash or hash-like structure with the
required keys, and the correct keys will be used as the subroutine
parameters.
=head1 IMPLEMENTATION
The default subroutine interface becomes C<qs{@}> like it
has been all along, but by using explicit interfaces we
can introduce a more extensive conversion step when required.
This system was proposed within RFC 61 as an implementation detail,
and after reading RFC 57 it became clear that the problems of stuffing
a set of data into the interface for an external function apply equally
to a native perl function.
I think that after settling on an extensible interface declaration
system, much cool stuff that cannot happen with the current lists
will be possible.
=head1 MIGRATION
perl5 prototype definition language will be one type recognized
by C<qs>, and perl6 argument coercion will be a proper superset
of perl5 argument coercion.
subroutines expecting hashes decomposed into arrays wouldn't
have a prototype indicating anything else, so that's what they'd
get.
=head1 CHANGES
rewrite to focus on the universality of
interfaces == parameter lists == structures
rather than expecting people to intuit that more readily
=head1 REFERENCES
RFC 57: Subroutine prototypes and parameters
RFC 61: Interfaces for linking C objects into perlsubs
e-mails from Chaim Frenkel
