mjl@ritcv.UUCP (Mike Lutz) (01/30/88)
Everyone else seems to be rambling all over the place on the "hot topic"
of the hour (operator overloading), so what the hell! I might as well
add some (marginally?) useful comments.
Way back in the early 70's, a "hot topic" in language design were so-called
extensible languages. In their fullest and least constrained forms, such
languages allowed one to extend not only the data types, but the very
form of control structures and overall language syntax. I remember a paper on
a spectacularly powerful syntax macro system for PL/I, with an example
where PL/I was turned into a special purpose geometry language.
Interest in these languages quickly waned, however, when the practical
problems of managing groups of these packages overwhelmed the perceived
benefits (what if I want to use the "geometry" syntax and some
"graphics" syntax, but they both define a "loop" construct in
incompatible ways). The general feeling seemed to be that extending
the syntax was a no-no, but extending data structures was a good
thing. (I happen to agree, and most of the abstract data type and
object oriented programming concepts follow these precepts).
However overloading, whatever its notational convenience, and however
much it may seem "obvious" in a local context, threatens to wreak the
same havoc as did syntax macros way back when. The fact that some have
essentially said that "intuition can guide interpretation" is
frightening to me - software based on "intuition" is software doomed to
failure. Remember: intuition says heavy objects fall faster than light
ones - want to build an engineering discipline on that foundation?
Mike Lutz
Rochester Institute of Technology
rochester!ritcv!mjl
--
Mike Lutz Rochester Institute of Technology, Rochester NY
UUCP: {allegra,seismo}!rochester!ritcv!mjl
CSNET: mjl%rit@csnet-relay.ARPAcrowl@cs.rochester.edu (Lawrence Crowl) (01/30/88)
In article <138@ritcv.UUCP> mjl@ritcv.UUCP (Michael Lutz) writes: >... However overloading, whatever its notational convenience, and however >much it may seem "obvious" in a local context, threatens to wreak the >same havoc as did syntax macros way back when. Each programmer works in a local context, so unless we form an international registry of function names, we must accept operation overloading. Whether this overloading is done with "+" or "add" is somewhat moot. In the absence of formal definitions, "intuition" is all we have for guiding function names and operator symbols. -- Lawrence Crowl 716-275-9499 University of Rochester crowl@cs.rochester.edu Computer Science Department ...!{allegra,decvax,rutgers}!rochester!crowl Rochester, New York, 14627