Re: Definable operators

Dave Lloyd <>
4 May 1997 22:44:02 -0400

          From comp.compilers

Related articles
[24 earlier articles]
Re: Definable operators (1997-04-20)
Re: Definable operators (David Rush) (1997-04-20)
Re: Definable operators (Craig Burley) (1997-04-22)
Re: Definable operators (Craig Burley) (1997-04-30)
Re: Definable operators (1997-04-30)
Re: Definable operators (1997-05-04)
Re: Definable operators (Dave Lloyd) (1997-05-04)
Re: Definable operators ephram@ear.Psych.Berkeley.EDU (Ephram Cohen) (1997-05-06)
Re: Definable operators (Francois-Rene Rideau) (1997-05-08)
Re: Definable operators monnier+/news/comp/ (Stefan Monnier) (1997-05-08)
Re: Definable operators (Craig Burley) (1997-05-08)
Re: Definable operators (Craig Burley) (1997-05-08)
Re: Definable operators (Dave Lloyd) (1997-05-12)
[8 later articles]
| List of all articles for this month |

From: Dave Lloyd <>
Newsgroups: comp.compilers
Date: 4 May 1997 22:44:02 -0400
Organization: Compilers Central
References: 97-03-037 97-03-076 97-03-112 97-03-115 97-03-141 97-03-162 97-03-184 97-04-027 97-04-095 97-04-113 97-04-130 97-04-164
Keywords: syntax, design, comment

Craig Burley ( wrote:
        {much omitted}
> ...I am pointing out there are at least two valid
> uses of the term "language" that we too often think of and use
> interchangably:
> 1. A systematic means of communicating ideas
> 2. A formal system of signs and symbols
> FORTRAN, C, C++, make, sh, and so on all define examples of (2).

The original ALGOL from 1958 was purely a language of type (1). It
was an Algorithmic Language for expressing algorithms principally in
journals and not to computers. This idea was still strong ten years
later but the new language Algol 68 was also a language for
communicating algorithms to machines.

As to your thesis against overloading, I believe you to be deeply
mistaken. Your use of C and Fortran 77 as defenses is particularly
risible: both suffer from the awful problem that I can override SIN
etc., at link-time. Any abstraction can be used to hide both
irrelevant implementation and significant semantics. It is the
craftsman's job to get the balance right as it is with English.
Elegance is the goal not some kind of entropic minimalism. A good and
powerful tool can help you create works that you would otherwise be
incapable of, but it can also take you straight to Hospital. These
things cannot be legislated, they can barely be taught, but they can
be learnt and are often but matters of personal or cultural taste.

But I can see that we can never agree on this one.

Where I think we agree is that computer languages are too keen to
define the grammar but leave the vocabulary to the reader. (Aside:
what makes Java interesting to me is that for once a language comes
with extensive universal libraries - Java is otherwise a rather
pedestrian language).

For example, with a typical list do you name the fields "head", "tail"
or "car", "cdr", or "this", "next" or something else. Over many years
I find that I am not very consistent on this most basic of naming!

Rather than spend effort in restraining the programmer in the language
I would rather invest some effort in defining a lexicon of terminology
for user-defined operators, functions, etc. Whether this be formalised
by an international standard or maintained as a dialect within a
project is perhaps less important but clearly as with English the
wider some vocabulary is understood, the greater its
applicability. Many software houses already maintain Coding Standards
including naming conventions and if peer code reviews are regularly
performed humans can enforce these standards with appropriate

Incidentally such a lexicon might reduce the anglocentric nature of
programming you espouse. Terms in the lexicon could easily be given
their correspondents in other natural languages providing a leg up for
automatic translation of (say) French software into Norse software (ok
it wouldn't be perfect but surely a great improvement).

Dave Lloyd
Oxford and Cambridge Compilers Ltd
Cambridge, England
[Humph. You sure couldn't override SIN at link time in the compiler
I wrote unless you declared it EXTERNAL. -John]

Post a followup to this message

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