Re: User definable operators

I've followed this thread with interest, having experienced most of
the phenomena described by others, e.g. impatience at the verbosity of
some people's programs, the incomprehensibility (to me) of many
mathematical papers on topics I thought I understood, easy
implementation of operator based languages and the beauty of being
able to define proper cross and dot products for my vector package
written in Algol-68 (this was fourteen years ago). For what its worth
here are my observations.


1. People complaining about the opaqueness of notation in mathematical
papers miss the point. Rigorous mathematical proof relies on strict
application of the rules for whichever symbolic system the writer is
describing. An important part of this approach is to deliberately
strip symbols of suggestive meaning, so as to force the reader to
back-reference to the definitions. This has nothing to do with
verbosity or conciseness - it's about forcing the reader to work hard
and not take things on trust. Like most engineers, I didn't understand
how important this is until I started collaborating with a serious
mathematician and had a chance to observe the way she works. It's got
very little to do with the way I construct a program or a piece of
hardware, and so I think that traditional mathematical practice has
little to teach us about how programming languages should look.


2. Languages which allow new operators to be defined can allow very
beautiful programs: particularly in areas such as vector and matrix
manipulation where well known operators exist but are not usually
available as primitives in programming languages. However, such
situations are rare.


3. Languages based purely on operators can have very beautiful
implementations, and can provide great power to those who understand
their use. The Algol-68 notion of every clause returning a result
(which derives from the essential operator oriented basis of the
language) allowed me to write concise and rather efficient loop
handlers which were hard to understand but great for my ego.


4. It is easy to get carried away. Implementing well-defined operators
for rather general datatypes is hard. Surprising interactions can be
hard to debug.


5. Programs containing lots of operators quickly become write-only
programs (that is, nobody can read the program and understand it
straight off). This arises from two effects.


(a) The eye is not very good at parsing ASCII representations of
operators: they quickly become just a string of punctuatuation symbols
indistinguishable from line noise. Typesetters of mathematical papers
understand this - there are rules for the spacing of operators and
large expressions use both vertical and horizontal spacing to clarify
the intent of the author. Look at the relevant parts of the TeX book
for examples of how to do it properly, and at the results of the
obfusticated C contests for examples of how to do it badly
(horrifically, actually, but very funny).


(b) Typical operators carry little mnemonic value, so lots of back
referencing is required to figure out what a program means. Multiple
levels of back referencing are lethal to understanding, perhaps due to
the rather low limit on our short-term memory capacity. In some
languages such as Forth and, even worse, the TeX language, back
referencing is effectively the execution paradigm. Although these
languages are not really operator based they display the same kind of
write-only characteristics. These languages allow you to quickly write
complicated things and then, if you're lucky, some months later you
can very slowly figure out how your program actually worked. This is
even more fun if you can write something very large and then give it
away so that others can lose chunks of their lives figuring out how it
works. Choose any TeX package you like as an example.




All in all, it seems throughout my programming career I keep falling
in love with conciseness and then getting very badly burnt. I've come
to the conclusion that lots of simple code is better then a little
subtle code for the simple reason that I am stupider than I think and
that I don't want to work as hard as a mathematician every time I read
one of my own programs. So give me long names, crude control
structures and not to many layers of referencing. For an eloquent
defence of dumb programming, see Tony Hoare's ACM award paper.


                                                      Adrian


--
    Dr Adrian Johnstone, Dean of the Science Faculty, Dept of Computer Science,
        Royal Holloway, University of London, Egham, Surrey, TW20 0EX, England.
Email: adrian@dcs.rhbnc.ac.uk Tel: +44 (0)1784 443425 Fax: +44 (0)1784 443420


--

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