[net.lang.mod2] overloading

treid@MITRE.ARPA (Thomas Reid) (03/04/86)

I'll jump into the overloading fray.

It is a tradeoff - sort of a forest and trees problem.  Without overloading,
you have super tight type checking but a tremendous proliferation of names to
remember.  The libraries are the size of trunks.  If you program as a hobby,
then remembering the exact formats of all of the library contents is an
exercise in always looking up in the manual.  If you live with the language
8 hours a da this will resolve itself.

On the other hand, overloading already exists in Modula-2 (arithmetic 
operators).  The discussion then evolves into a language designer's issue:
how much.  Wirth decided very little and removed basic sequential I/O. 
I believe that this was a mistake and makes using the langua more difficult
to use without significantly increasing its soundness.

Why do I feel this way?  For the same reason that "+" is overloaded: the
concept of sequential I/O is so basic to computing that its semantics are
inherently understood in many different contexts.

Thus, I would bring basic sequential I/O back into the language with variable
length parameter lists of overloaded parameters.  In my humble view, the
increase in programmer productivity and listing readability is worth the
loss in tightness.  
Where do you stop between this one slight perversion of the language's purity
and the enormity of Ada?  The basic rule I would use is: consider the extension 
if there is "universal" concensus on how to implement the construct and that
the increased complexity is more than offset by the combination of 
understandability and productivity.

Flames welcome.  Tom Reid.

ark@ut-sally.UUCP (Arthur M. Keller) (03/05/86)

In response to Tom Reid, even Ada has decided not to make any
extensions to make input-output easier.

I've often thought about allowing procedures in an Algol-based
language to have a multiple number of parameters and have it
equivalent to multiple calls with each parameter one at a time.  Then
Pascal-like input-output statements could be in a language, and if
generics or overloading were also supported, input-output statements
supporting any type could be written merely by writing the one
procedure that handles writing of any particular new type.  This
is my view of how extensible input-output could work.  It can easily
be done in Lisp.  I would like to see Algol-like languages that
support it as well.

Arthur
-- 
------------------------------------------------------------------------------
Arpanet: ARK@SALLY.UTEXAS.EDU
UUCP:    {gatech,harvard,ihnp4,pyramid,seismo}!ut-sally!ark

gillies.osbunorth@XEROX.COM (03/05/86)

Here's a total flame.  No
I strongly disagree that basic sequential I/O should go into a language.
Here at Xerox, could you have anticipated these I/O methods, or would
you like to change our compiler every time we prototype a better I/O
system (which we've done several times already, with new modules)?

* Multi-national strings, with 8-bit font codes and 8-bit character
codes
* A more efficient type of string, that is used mostly for network
servers
* Routines to mimic C's printf() and putchar() functionality
* The ability to write to a random window or subwindow on the screen.
* Formatting routines that convert not just numbers, but dates,
processor IDs,
    and sockets into a myriad of forms.

If you feel we must standardize "because I/O is so basic to computing"
then we must not understand the basics, which I think is a fair
statement.  The basics are redefined every year.

It is amusing to note that only 1/3 of the systems we build here use
even the CHARACTERS and STRINGS defined by the language [MESA].  The
others use their own, and essentially waste the compiler constructs for
creating such objects (luckily MESA doesn't have i/o or string
manipulation primitives, which would have surely gone to waste).

Thus, any I/O constructs that were built into the language, would
presumably operate on types already in the language, and would have gone
to waste in 2 out of 3 of our systems.  The End-to-End argument seems to
apply here:

"Functionality, placed at a low-level in a system [the compiler] may be
redudant or of little value when compared with the cost of providing
them at that low level.  Low-level mechanisms to support these functions
are justified only as a performance enhancement"

[since many clients must reimplement this functionality anyway]

					Don

jantypas@WOLF.UUCP (03/06/86)

To: Donald_W._Gillies.osbunorth@Xerox.arpa
Subject: Re: Overloading
Date: Wed Mar  5 13:05:59 1986


True, I/O should NOT be part of the language itself.  Pascal taught us that.
However, the usual problem still persists in languages such as C and Modula:
As usual, Joe down the street likes his I/O standard better than yours and
because his is only $99.95 and yours isn't, we eventually get TWO standards
and neither is compatable with the other, not even taking into account things
such as file formats etc.  If someone could come up with a standard people
would stick with, then we could talk about portability. .. but the "standard
standards" are usually the lowest common denominator and hence anyone and
everyone is encouraged to extend the standard once again.  

While I don't disagree with your flame, I do feel that your term of "standard"
needs defining.

John Antypas 

UC San Diego
uucp: ...!sdcsvax!jantypas
arpa: jantypas@sdcsvax.ucsd.edu

1

siebren@boring.uucp (Siebren van der Zee) (03/06/86)

I don't think the discussion about overloading belongs in a
newsgroup about Modula 2, since this language does not provide
overloading facilities. Would you please subscribe to net.lang
or some other newsgroup that I do not read because of news-overload?

	Thanks in advance!
	Siebren van der Zee
	E-mail: siebren@mcvax

iwm@icdoc.UUCP (Ian Moor) (03/07/86)

In article <274@daimi.UUCP> jnp@daimi.UUCP (J|rgen N|rgaard) writes:
> Why not extent this implicit overloading an make it
>explicit and let user-defined overloading be allowed ? 
>In my opinion the distinction between (some) predefined 'overloaded'
>routines and user-defined routines is frustrating.

Having implemented a language with overloading (Hope) I found that
the same mechanism for handling overloading of predefined routines 
can be applied to user-defined ones, determine the type of the arguments 
and compare with the possibilities to determine which code to produce.

It is most frustating to find a language where predefined functions
are 'special' - after all if the compiler can cope with them it should
be able to manage user defined  ones.

-- 
Ian W Moor
  UUCP: seismo!mcvax!ukc!icdoc!iwm
  ARPA: iwm%icdoc@ucl                        
           
 Department of Computing   Whereat a great and far-off voice was heard, saying,
 Imperial College.         Poop-poop-poopy, and it was even so; and the days
 180 Queensgate            of Poopy Panda were long in the land.
 London SW7 Uk.