Re: User definable operators

apardon@rc4.vub.ac.be (Antoon Pardon)
7 Jan 1997 12:29:35 -0500

          From comp.compilers

Related articles
[17 earlier articles]
Re: User definable operators genew@mindlink.bc.ca (1996-12-28)
Re: User definable operators WStreett@shell.monmouth.com (1996-12-29)
Re: User definable operators adrian@dcs.rhbnc.ac.uk (1997-01-02)
Re: User definable operators hrubin@stat.purdue.edu (1997-01-02)
Re: User definable operators anw@maths.nottingham.ac.uk (Dr A. N. Walker) (1997-01-03)
Re: User definable operators WStreett@shell.monmouth.com (1997-01-03)
Re: User definable operators apardon@rc4.vub.ac.be (1997-01-07)
Re: User definable operators icedancer@ibm.net (1997-01-07)
Re: User definable operators wclodius@lanl.gov (William Clodius) (1997-01-09)
| List of all articles for this month |
From: apardon@rc4.vub.ac.be (Antoon Pardon)
Newsgroups: comp.compilers
Date: 7 Jan 1997 12:29:35 -0500
Organization: Brussels Free Universities (VUB/ULB), Belgium
References: 96-12-088 96-12-163 96-12-181 96-12-185 97-01-015 97-01-028
Keywords: syntax, design

Wilbur Streett (WStreett@shell.monmouth.com) wrote:
: hrubin@stat.purdue.edu (Herman Rubin) wrote:


[ cut ]


: > There was no reluctance on the part of the computer language people
: > to take quite standard mathematical symbols, sometimes even
: > overloaded in mathematics, and use them with totally different
: > meanings, and the mathematical meanings were made unusable. I can
: > come up with more than a dozen such. At least the originators of
: > Fortran apologized for their restrictions, and the use of * and **,
: > because of the capabilities of their hardware.


: I don't like that either. But part of learning a new language is
: learning the conventions. I think that reading a piece of software is
: like learning a new language. I hope that a program is more like a
: person speaking than a whole new language. With notation overloading,
: it's a new language with every line, and the same symbol on two
: different pages may mean two very different things.


It is no more a new language with notation overloading than it is
without. In most languages the same symbol on two different pages may
already mean two different things. As names of variables in
different pieces of code can be the same. IMO it doesn't become a new
language because I'm allowed to reuse the name "Is_Empty" as a
function name for any type for which it is meaningfull to speak of
an empty object. Nor do I think it becomes a new language because I am
allowed to reuse "+" for types for which it is meaningfull to speak of
an adding operator.


There was a time we used very little abstraction in natural language.
That is why we have words like pigling, calf, puppy, kitten, foal
etc. These can all be called the young and it doesn't seem to bother
people that these young can be kittens as well as foals depending on
context. In the same way I see nothing wrong when a programmer sees
the possibility to abstract on something to use the same name or
symbol for every instantiation of this abstraction instead of using a
type specific name.


[ cut ]


: Taking the idea of "+" again, how do you know if the notation has been
: overloaded completely and what the implementation's abstractions are?


The same way that you know that "insert" really does an insert
and not a delete. By inspecting the code.


: There isn't any guarentee that a notation for a given type is going to
: run through the same code that another line that appears exactly the
: same is going to run through. What follows is that you can then have
: two lines of code that "appear" to be exactly the same, but then have
: intermediate layers of complexity that can't be identified directly.


So what? In terms of understanding the program I think that is
unnecessary. If adding is appropiate and well understood for the
type then understanding what is done should be sufficient. If you
are concerned with debugging and checking that the right adding
operator is called for the right type the compilor should be able
to produce a listing where overloaded functions are properly
identified where thet are used.


: A + B when the variables are number means add them together
: A + B when the variables are strings means concatenate the strings


: What does A + B mean when A was a string, but B is now a number?


Its meaning is undefined.


: Where was the type of A and B defined? Is it within a single screen?
: A single module? A single program? Several programs? Were A and B
: used in different ways in different places? Are the types defined
: numbers or strings or something else?


What difference does it make? If the purpose of the code is to solve
an equation of the form: X - B = A. I don't care whether A and B are
integers, naturals, floats complex numbers, matrices or whatever type
of objects it makes sense to solve this kind of equations for. "A + B"
is the answer for that problem regardless of type. Using "+" as the
concatenation operator for strings may not be a good choice but
(possible) poor/mis use of a feature is not a good argument against a
feature.


If you suspect there are problems with picking the right operator for
the right type the compilor should be able to identify which
particular operator he has chosen in each instantiation.


: I don't believe in overloading VARIABLE NAMES within a program. I
: certainly would not agree with overloading other notation.


Does this mean, you see to it that all your index variables within a
program have different names.


--
Antoon Pardon Brussels Free University Computing Centre
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.