Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!burl!ulysses!gamma!epsilon!zeta!sabre!petrus!bellcore!decvax!decwrl!amdcad!lll-crg!seismo!ut-sally!ark From: ark@ut-sally.UUCP (Arthur M. Keller) Newsgroups: net.lang.mod2 Subject: Re: extensions, a modest proposal Message-ID: <4305@ut-sally.UUCP> Date: Thu, 27-Feb-86 03:17:01 EST Article-I.D.: ut-sally.4305 Posted: Thu Feb 27 03:17:01 1986 Date-Received: Sat, 1-Mar-86 01:39:07 EST References: <8602251623.AA03090@orb.sun.uucp> Reply-To: ark@sally.UUCP (Arthur M. Keller) Organization: U. Texas CS Dept., Austin, Texas Lines: 55 I beg to differ with my esteemed colleague, Mr. Rob Nagler, about the interaction between overloading (and generics, for that matter) and strong type checking. My comments here apply to the issues in general without reference to the particular language. Without overloading and generics, strong type checking is much easier as there is no possible ambiguity. With overloading, the correct procedure is used by a resolution process that uses strong type checking. (I don't believe overloading can be resolved at compile time without strong type checking.) With overloading, controlled generic capability can be achieved. Why would anyone want that? Well, would you want to have to distinguish between + for integer and + for reals? Would you want to have to invent unique names for each procedure that did an equivalent thing to its data type? I see nothing wrong with Mr. Nagler's example. In fact, I like it because I wouldn't want to have to remember to use (say) PUT-ARRAY instead of PUT. Note that even with overloading, all the parameters have to be compatible with exactly one procedure spec. In the + example above, that could mean precluding adding an integer to a real, if so desired. In my point of view, the main benefit of strong type checking is compile-time versus run-time checking. Since overloading is resolved completely at compile-time, I don't see how it is incompatible with strong type checking. Some generic capability (such as that in Ada) is equivalent to a compile-time expansion of the generic package as if it were a macro, and then using overloading to resolve it. This too is compatible with strong type checking, although the generic package usually cannot use any features not common to all potential types for the generic (i.e., a type for a generic must support all the operators and procedures needed by the generic package). A true generic would have the capability of deciding what to do based on the type. If done at run-time, this is clearly not compatible with strong type checking. If done at compile-time, you can use compile-time expansion as if the generic package were a macro with macro conditionals. In some sense, overloading without generics can be thought of as a limited collection of macro expansions of the generic that used macro conditionals. --- Sometime, when I'm in a flaming mood, maybe I'll talk about sinister functions (i.e., functions that go on the left) and their relationship to the generalization of array indexing as locating an item in a structure. (That is, why shouldn't retrieval and storage into any structure have the syntactic nicety of arrays; and how can I replace an array with a complex data structure (i.e., if the array is sparse) without having to modify the code using the array.) I doubt if this is the right audience. Constructive comments on where to send this, as well as expressions of interest in discussing this, are welcome. Arthur -- ------------------------------------------------------------------------------ Arpanet: ARK@SALLY.UTEXAS.EDU UUCP: {gatech,harvard,ihnp4,pyramid,siesmo}!ut-sally!ark