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.