[Prev][Next][Index][Thread]
Re: Operator overloading [was: Re: Does my ideal language exist?]
In article <Pine.GSO.3.96.1000607190423.8992J-100000@tardis.tardis.ed.ac.uk>,
Hugh Greene wrote:
>If you want a <double-float> from a <single-float> you have to convert with
>the function "as". However, you don't have to explicitly convert all the
>time because functions like "\+" are defined to cover all combinations of
>the built-in concrete classes. If you try to, say, add two objects for
>which no applicable method can be found, you'll get either a runtime
>exception or a compile-time error, depending on when there's enough type
>information.
Algol 68 has strong typing. An integer of mode INT has a specific
number of bits, but if it has mode LONG INT it may have more,
depending on the implementation.
Operators for LONG INT operands exist in the standard library
(standard prelude) for all the usual arithmetic operators (+, -, *,
/, **) and can be defined for any other operator. The same applies to
REAL and LONG REAL. Any integer of mode INT cannot be automatically
converted to an integer of mode LONG INT: you have to use the LENG
operator. Similarly with SHORT SHORT INT to SHORT INT. There is
another operator SHORTEN which goes the other way around.
Operator overloading in Algol 68 is possible (and typical) because
the context of an operand is `firm' which means that integers cannot
be `widened' to real or complex numbers, nor converted into arrays
(`multiples' in Algol 68).
>Initially I though explicit conversion would be irritating but in (about 3
>years of) practice it hasn't been. Then again, I haven't done that much
>heavily numerical programming in Dylan (and maybe I've just got used to it
>:-).
Algol 68 is very good with numerical programming.
>> It's certainly possible to write object-oriented code in classic
>> procedural languages, but I'd recommend using a language that's designed
>> for the job.
>
>In particular, in the presence of implicit coercions (user extensible via
>copy constructors in C++), the language may require more effort on your part
>(e.g., the "explicit" modifer for said C++ constructors) just to prevent
>things you didn't intend (and probably didn't want) from happening
>automatically.
The `automatic' conversions in Algol 68 are known as `coercions' and
are well-defined. Every context has a strength which is also
well-defined. At any point, a cast can ensure that a particular
construct will yield the mode required, but not like C.
>You may or may not be willing to trade this "riskiness" for some other
>benefits a particular language provides. In Dylan part of the trade-off is
>that the default <integer> class, for example, is only guaranteed to provide
>28 bits of precision, not 32 (although that's not related directly to
>overloading etc.). In practice this is okay, too: often you just want a
>loop index to be "big enough" and you can find out what the
>"$maximum-integer" is; when you do need 32 bits, a particular implementation
>may provide a way to get them.
In Algol 68, environment enquiries will provide the programmer the
necessary information to determine the size of any particular
precision. For example, the value `int lengths' (of mode INT) is 2 if
both modes INT and LONG INT exist. This doesn't just mean that you
can write
LONG INT li = LONG 36
but also that `max int' has a different value from `long max int'.
Any Algol 68 compiler should allow you to write
LONG LONG LONG LONG REAL r = LONG LONG LONG LONG 2.0
but there is no guarantee that that precision is distinguishable from
the next precision down. Again, the value `real lengths' will tell
you what is available. There are other values which enable the
programmer to determine the exact precision (particularly important
for numerical calculations).
>> > >And, again, I have had painful experiences with overloaded operators
>> > >changing the meaning of expressions in surprising and dangerous ways.
>
>From my experience, I can certainly sympathise in terms of numeric type
>promotions/truncations etc. in C/C++.
Just doesn't happen in Algol 68!
Regards
--
Sian Leitch (Software Engineer specialising in Algol 68)
Algol 68 for Linux will be available from me.
Follow-Ups:
References: