🚀 go-pugleaf

Bimal Shah (c2bs@dmu.ac.uk) wrote:

>In Modula-2, is it possible to call a procedure which
>has paramenters of AnyType ? e.g

>PROCEDURE AddOne(VAR number:AnyType);
>(* code here *)
>END AddOne;

>I require this, as the same operations need to be carried
>out on different types... and i'd rather not have x procedures
>for x different types.. as this looks really messy.

It can be done, and someone has already responded with a couple
of solutions.  I'm not at all convinced, however, that it should
be done.  The approach of writing x procedures for x different
types is likely to prove a lot cleaner in the long run.

If all of the procedures consist of essentially the same code,
then writing them is no great effort - just use copy-and-paste
in whatever editor you prefer.  If the code is different, then
you have to write different code for the different cases no matter
what approach you use.

Consider the following example:
    PROCEDURE AddOne (VAR number: AnyType);
        BEGIN
            CASE number.kind OF
              | integer:  INC(number);
              | real:     number := number + 1.0;
              | complex:  number.re := number.re + 1.0;
              | string:   Str.Append (number, "1");
              |   [etc]
            END (*CASE*);
        END AddOne;

Now compare this with the "x different procedures" approach:

    PROCEDURE IntAddOne (VAR number: INTEGER);
        BEGIN
            INC (number);
        END IntAddOne;

    PROCEDURE RealAddOne (VAR number: REAL);
        BEGIN
            number := number + 1.0;
        END RealAddOne;

    PROCEDURE CxAddOne (VAR number: Complex);
        BEGIN
            number.re := number.re + 1.0;
        END CxAddOne;

    PROCEDURE StringAddOne (VAR number: ARRAY OF CHAR);
        BEGIN
            Str.Append (number, "1");
        END StringAddOne;

Which solution is messier?  I submit that the solution with the
big CASE statement is the messy one, especially if you extend it
to a lot of different types.  True, the second solution takes more
lines of code; but it's much easier to read, it was also easier
to write, and if subsequently you have problems with your code
then it will be easier to track down the problem.  (For example,
there's probably a bug in the string operation above, since I
didn't bother to look up the manual for this; but fixing the bug
would require working on only one procedure in isolation.)

You might object to the proliferation of names above, where
each procedure has a different name; but in real code those
different procedures would be in different modules anyway
(it makes the code cleaner if you don't try to make one module
work on several different types), and then you can give them
the same name if you wish.

>Any pointers on books, FAQ would also be great.

The FAQ was posted to this group only recently.  It's very
likely that it's still on your news server.  If not, point
your WWW browser to my home page (see signature below), and
you'll find lots of information by following the obvious links.

--
Peter Moylan                       peter@ee.newcastle.edu.au
                           ftp://ee.newcastle.edu.au/pub/www/Moylan.html