phipps@fortune.UUCP (Clay Phipps) (03/28/84)
With regard to the allegation about PL/I:
PL/I, for example, gets around the entire class of conversion problems in
parameters to functions by passing not the parameter itself but a pointer
to a list of parameter descriptor blocks, which indicate the type of the
argument, allowing completely generic functions.
This above allegation does *not* describe a property
of the PL/I language, nor do the language characteristics
require such an approach. Furthermore, the above allegation
is not even typical of code emitted by PL/I compilers with which I am familiar;
these are predominately the IBM PL/I compilers.
Data type conversions are typically performed either with in-line code
or in complicated cases unsupported by most other languages
(e.g., float to string; do not confuse this with C "casting"),
by calls to run-time routines as needed.
IBM's System 360 and 370 PL/I compilers pass arguments
to functions and procedures as a linear list of pointers to the arguments,
in accordance with general System 360 and 370 software conventions.
This convention is analogous to passing pointers to arguments
(instead of the arguments themselves) on the stack of other machines.
Scalar arguments are passed with the same efficiency as in FORTRAN.
Variables are typically passed "by reference"; expressions are "by value".
There are no descriptors involved at all.
For array and string (distinct from array of character in PL/I) arguments,
the argument pointer often points to a descriptor, but that descriptor contains
address, bounds, and stride information, not data type information.
A descriptor is usually not produced or passed for calls to routines
in the same compilation unit as the caller if the array or string argument
has constant ("fixed size") bounds.
Structures are passed by reference; there typically is no descriptor.
In certain well-defined but usually rare cases (use of the "refer" option ?),
there is a descriptor passed for structures,
and it may contain structure field data type infomation (I forget).
This case is at odds with the general tone of the excerpt above.
The "generic" attribute is handled entirely at compilation time
by (the compiler) matching the formal argument types for the specific routines
in the generic family of routines to the types of the actual arguments;
based on this matching, the compiler emits code to call a specific routine;
there is no choice made among specific routines at runtime.
This is a generalization of FORTRAN's ability to select,
for example, the specific sine routine ("RSIN" [?], "DSIN", "CSIN")
for the generic sine routine "SIN" based on the type of its argument.
No data type descriptors are required for PL/I nor FORTRAN.
I don't recall the UNIVAC PL/I being much different from IBM's
in its handling of arguments.
I cannot vouch for DEC, DG, Honeywell, or PR1ME PL/I.
-- Clay ("I still like PL/I") Phipps
--
{allegra amd70 cbosgd decwrl!amd70 harpo hplabs!hpda
ihnp4 megatest nsc oliveb sri-unix ucbvax!amd70 varian}
!fortune!phippsbarmar@mit-eddie.UUCP (Barry Margolin) (03/29/84)
Multics PL/I will pass full descriptors when necessary. This is because we have a language extension which allows a procedure to be declared "options (variable)", meaning that the procedure may be called with a variable number of parameters and varying data types. Of course we also pass descriptors in the other case that Clay Phipps mentioned: when an array or string parameter has a *-extent. -- Barry Margolin ARPA: barmar@MIT-Multics UUCP: ..!genrad!mit-eddie!barmar