bertrand@eiffel.UUCP (Bertrand Meyer) (01/20/90)
A planned extension for variable-number argument lists in Eiffel
----------------------------------------------------------------
This is the fourth of a sequence of postings describing
changes envisioned for version 3 of Eiffel.
These are cleanup changes and do not affect anything fundamental.
The particular change described here is an extension, so it does
not affect any existing software. (The only incompatibility is that
any existing class called MULTI would have to be renamed.)
I should add that I am not absolutely convinced this particular
extension is needed. The result looks nice, and I am pretty
much convinced that if routines with variable number of arguments
are deemed necessary they should be done as described here;
but the question is whether it is worth it. Feedback will
be appreciated.
----------------------------------------------------------------------
|WARNING: The extension described here is envisioned for version 3 of |
|the environment, not to be released before late 1990. |
| |
|Any change in the language supported by Interactive's tools |
|will be accompanied by CONVERSION TOOLS to translate ``old'' syntax |
|into new. Programmers will NOT need to perform any significant work |
|to update existing Eiffel software. |
| |
|This posting is made solely for the purpose of informing the Eiffel |
|community about ongoing developments. Although the posting has been |
|preceded by careful reflection and internal discussions within |
|Interactive, we make no commitment at this point that the features |
|described here will actually be included, and, if they are, that |
|their final form will be the exact one shown below. |
----------------------------------------------------------------------
Purpose of the extension.
-------------------------
The purpose of the extension is to allow the declaration of Eiffel routines
with a variable number of arguments.
Clearly, there are more pressing problems in the world and Eiffel
programmers have been surviving quite well without any such facility.
Many people do like, however, the flexibility of routines for which the
number of arguments is not known in advance. Printing procedures are
the classical example.
The mechanism may also be useful at the level of interfaces between
Eiffel and other languages such as C and (some versions of) Fortran
which support variable numbers of arguments; an example in C is
printf.
The language extension
----------------------
The Kernel Library now includes a generic class MULTI [T].
The interface (short form) looks like the following (see FIXED_LIST
in the Data Structure Library):
class interface MULTI [T] exported features
empty, offright, start, forth, position, item, i_th, ...
feature specification
empty: BOOLEAN
offright: BOOLEAN
-- Is cursor past the last item?
start
-- Move cursor to first item
require
not empty
ensure
not offright
forth
-- Move cursor one position forward
require
not offright
position: INTEGER
-- Index of current cursor position
item: T
-- Element at current cursor position
require
not offright; not empty
ensure
Result = i_th (position)
i_th (i: INTEGER): T
-- Value of i-th element
require
not empty; i >= 1; not offright
end -- class interface MULTI
An instance of this class represents a read-only list of objects of type
T, accessible either sequentially (through start, forth, item, over)
or by direct access through an index (i_th). This is appropriate
for a list of actual arguments of the same type.
Of course the actual arguments do not have to be all of EXACTLY
the same type.
Items in an instance of MULTI [A] may be instances of not just A
but also the descendants of A. In the most general case,
MULTI [ANY] covers lists of objects of any type.
(This is what you would probably declare as the type of
arguments of a general-purpose, variable-argument print procedure.)
An entity may be declared of type MULTI [...] if and only if it
is a formal argument of a routine. (In this sense class MULTI is
special: its existence is part of the language.) There is one constraint:
[1]
A formal argument of a routine may be declared of type MULTI [A]
if and only if none of the adjacent arguments (the one declared
before and the one declared after, if any) is of type MULTI [B]
for some B such that A conforms to B or B conforms to A.
The purpose of this rule will be clear shortly.
``Conformance'', defined rigorously in ``Eiffel: The Language'',
is the relation which connects any two types such that (roughly
speaking) an instance of one may be an instance of the other.
In particular, for classes, B conforms to A if B is a descendant
of A (direct or indirect heir).
If a formal argument a is declared of type MULTI [A], then the possible
actual arguments are zero or more expressions of type A or a descendant.
This explains the role of rule [1]: avoiding any ambiguity.
For example, if we have the routine declaration
p (x: A; y: MULTI [A]; z: MULTI [B]; u: C)
and rule [1] is satisfied, meaning that A does not conform to B and B
does not conform to A, then possible class are (with the lower-case
entity names chosen to indicate their types):
p (a1, a2, a3, b1, b2, b3, b4, c1)
-- 3 arguments for MULTI [A], 4 for MULTI [B]
p (a1, c1)
-- None of either MULTI [A] or MULTI [B]
p (a1, a2, c1)
-- One for MULTI [A], none for MULTI [B]
etc. Clearly, the first and the last argument of p are compulsory
since they are not of the MULTI form; a single A actual argument is
preempted by the first formal argument.
A note on conversion of existing software
-----------------------------------------
The only problem in converting existing Eiffel software is the
need to find another name for any class called MULTI. This word
becomes a reserved word.
--
-- Bertrand Meyer
bertrand@eiffel.combertrand@eiffel.UUCP (Bertrand Meyer) (01/20/90)
I found two oversights in the referenced message. Below are the corrected
lines. I apologize for the errors.
The line numbers are approximate.
Line 143
speaking an instance of one may be assigned to an instance of the other.
^^^^^^^^^^^
Lines 159-160
p (a1, a2, a3, b1, b2, b3, b4, c1)
-- 2 arguments for MULTI [A], 4 for MULTI [B]
^
--
-- Bertrand Meyer
bertrand@eiffel.com