Re: Definable operators (was: Problems with Hardware, Languages, and Compilers)

creedy@mitretek.org (Chris Reedy)
14 Mar 1997 00:06:26 -0500

          From comp.compilers

Related articles
Problems with Hardware, Languages, and Compilers hrubin@stat.purdue.edu (1997-03-07)
Definable operators (was: Problems with Hardware, Languages, and Compi rrogers@cs.washington.edu (1997-03-09)
Re: Definable operators (was: Problems with Hardware, Languages, and C sethml@ugcs.caltech.edu (1997-03-13)
Re: Definable operators (was: Problems with Hardware, Languages, and C rrogers@cs.washington.edu (1997-03-13)
Re: Definable operators (was: Problems with Hardware, Languages, and C creedy@mitretek.org (1997-03-14)
Re: Definable operators (was: Problems with Hardware, Languages, and C nmm1@cus.cam.ac.uk (1997-03-16)
Re: Definable operators (was: Problems with Hardware, Languages, and C andy@cs.Stanford.EDU (1997-03-16)
Re: Definable operators (was: Problems with Hardware, Languages, and C malcolm@sedi8.nag.co.uk (1997-03-16)
Re: Definable operators (was: Problems with Hardware, Languages, and C apardon@rc4.vub.ac.be (1997-03-18)
Re: Definable operators (was: Problems with Hardware, Languages, and C jenglish@crl.com (1997-03-18)
Re: Definable operators (was: Problems with Hardware, Languages, and C nmm1@cus.cam.ac.uk (1997-03-21)
| List of all articles for this month |
From: creedy@mitretek.org (Chris Reedy)
Newsgroups: comp.compilers,comp.lang.misc,comp.arch.arithmetic
Date: 14 Mar 1997 00:06:26 -0500
Organization: Mitretek Systems
References: 97-03-037 97-03-043
Keywords: syntax, design

rrogers@cs.washington.edu (Richard Rogers) wrote:


> >[.... I used IMP72, a language where
> >you could add any operations you wanted, and it was awful. -John]
>
> Why was it awful? It seems to me that mathematicians would be quite
> frustrated if they were restricted to using + - * and / in their
> papers... Granted, it would require some discipline (what language
> feature doesn't? :-), but we seem to be pretty good at understanding
> traditional math notation where it's normal to define appropriate
> operators for the objects under consideration. But I've never used a
> language that allowed operator definition....


Having been trained as a mathematician ...


You're correct that mathematicians invent new terminology and
notations all the time. (In fact, there are times when I think that's
what mathematics is.) But, when writing a paper, there is a standard
protocol for this:


  1. First, if it's really a new terminology, you have to introduce it
and explain it in the paper prior to using it. (E.g. "A group is
defined as ...".)


  2. If you are using notation that's introduced in another paper,
generally one which will be known to your readers, you can introduce
the notation by explicitly referring to the paper. As things mature a
little more, notations can be introduced by referring to text
books. (E.g. "In this paper, we use the definition of group as found
in ...".)


  3. Finally, there reaches a point where you can assume that all
researchers in the area of interest will be familiar with the
terminology and no reference is needed. (E.g. "Consider the group of
automorphisms of ...".) This is typically the point where the concept
is included in undergraduate or first-year graduate level texts.


It is interesing that in a research paper, you must indicate what
concepts you are including from other references. This is a different
from, for example, the C/C++ "#include xyz.h", which doesn't tell you
that xyz.h might include a definition of a class foo.


It seems to me that these stages should correspond to some sort of
maturing of software concepts starting with ones that are defined in a
given program, moving to ones that are part of a (standard) library,
and finally(?), to ones that are part of the programming language.


  Chris


Dr. Christopher L. Reedy, Mail Stop Z667
Mitretek Systems, 7525 Colshire Drive, McLean, VA 22102-7400
Email: creedy@mitretek.org Phone: (703) 610-1615 FAX: (703) 610-1603
--


Post a followup to this message

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