PL/I Arguments / Re: C Language Problems ... Leave It Be?

[Clay Phipps]

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!phipps