Re: optional parameters

paulb@pablo.taligent.com (Paul Beusterien) writes:


> > How are optional parameters implemented ? I'm sure the technique is
> > not the same for C++ than for CommonLisp (and, for CommonLisp
> > &optional are probably not handled the same as &key and as &rest).


On Operating Systems like Multics (where the style is that of
any language being able to call any other language) the method is
to pass a pointer to the parameter-block (perhaps in a known
register, perhaps at the begging of a known placed in the
called-program's stack, perhaps ...). The block is in three parts.
Part 1 is a structure with two elements : numparms and numdescrs.
These two integers tell the number of parameters and number of
descriptors respectively. This is passed on every call. If there
are no parameters, or descriptors, those numbers are zero.
Part 2 is an array of pointers to the arguments. The number of
elements of the array is numparms. Of course if there are no
parameters, Part 2 is not present.
Part 3 is an array of pointers to the descriptors. The number of
elements of the array is numdescrs. Of course, if there are not
descriptors, Part 3 is not present.




This means that if one calls from a language like PL/I (which uses
descriptors) to language like FORTRAN (which does not), then the
FORTRAN runtime merely ignores the descriptors. Then, like pre-ANSI
C, they had better be "right" because there is no way to check.


If one calls from FORTRAN to PL/I, then there are no descriptors
passed. Since the PL/I runtime would usually look for descriptors,
at first glance this appears to be a problem. But it is not, since
FORTRAN is not capable of passing anything that needs descriptors
to be passed! Again, there is no checking, and it had better be right.


If one calls from PL/I to PL/I, descriptors and both passed and
expected. These descriptors are used to check (at runtime) that
the right kind of arguments (or conformable one, or co-ercable ones)
were passed. And if the wrong ones were passed, then an exception
(called a condition in PL/I) can be raised (signalled) and the problem
handled (caught in an on-block) by the routine that did the miss-call.


Of course if one calls from FORTRAN to FORTRAN (or C to C), there is
no error-checking in the usual non-varying calls. For varying calls,
the style is the same as PL/I to PL/I.


------------------------------------------------------------
Ada (both Ada83 and Ada95) have a different style. Both of them
define what is often referred to as "default values" for arguments.
Then any arguments one does not supply are filled in from the
default values. This gives the appearance of
varying-number-of-parameters, while in reality a full check is
done at compile-time, so the common C and FORTRAN problems of
passing the wrong arguments cannot happen.


And if one really wants "truly varying" number-of-args in Ada,
one can simply pass an array of varying length, and extract the
length of the array in the called program. One needs to code an
extra pair of parentheses, and perhaps even use named-parameter
notation. However, that is significantly less kludgy than being
forced to keep track of the size of an array separately, and pass
the data as two arguments, that one must do in FORTRAN or C.




------------------------------------------------------------
To learn something about Ada, including lots of information on why
the language helps the programmer to write safe programs
in circumstances that often result in faults in programs
written in language *not* designed for software engineering,
you might want to take the Lovelace tutorial. It's found on
the WWW through http://lglwww.epfl.ch/Ada/ at
    http://lglwww.epfl.ch/Ada/Tutorials/Lovelace/lovelace.html
--
Paul D. Stachour, Software Engineer and Methodologist
9532 First Avenue South 260-6A-08 3M Center
Bloomington, Minnesota 55420 St. Paul, Minnesota 55144
(612)-884-5977 stachour@winternet.com (612)-733-5217 pdstachour@mmm.com


--

Return to the comp.compilers page.
Search the comp.compilers archives again.