Re: User definable operators

Wilbur Streett <WStreett@shell.monmouth.com> wrote:
>>>Notation has to be overloaded to be of reasonable length.


>So what is more important is that the notation is of "reasonable"
>length than it follows generally accepted and defined abstractions?


Whose generally accepted and defined abstractions? 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.


Also, the mathematical conventions evolved. Anyone could put any
notation in his papers, WITH EXPLANATION, and some of them stuck. As
for his own use, why should anyone care? To introduce them in a
program would require telling the compiler what they mean, and I doubt
that the compiler would care.


>Suppose for a minute that I did the same with the English language?
>For the sake of demonstration I decided to change what each of the
>words in the previous sentence mean. Then you have to resort to the
>more extended reference to determine what the previous sentence means,
>because you have to check to be sure if the notation is the expected
>notation or the new extended notation. That means that the notation
>is NOT of reasonable length, but that you have to be sure to
>understand all of the supporting notation (which is not in front of
>you) in order to be able to understand the notation in front of you.


If one starts a problem by saying "let x be ...", etc., this can be
referred to WHEN NEEDED, but the logical structure understood. The
same holds for operators. But in many cases, these "new" operators
are the standard ones in mathematics, which the user already knows, or
are such simple things as abbreviations for "pack" and "unpack".


The compiler has to convert things to machine language, anyhow, and
the user should be able to get at that, and not have to use the
assembler language, designed with the idea of making it difficult to
for a person to use. I would have little problem with doing that,
myself. A versatile macro expander, with the macro structure being up
to the user, and using weak typing, would go a long way here and
elsewhere. This would be a totally non-optimizing mini-compiler for a
language with few constants.


..................


>> By the time one reads the lengthy variable names which seem to
>> delight the computer people, the structure of the expression is
>> lost.


>So long words confuse you? I don't like them either. But it's not
>the length of the words that make a program structure readable or
>unreadable.


I suspect that most mathematicians would disagree highly. We start
teaching the use of short symbolic formulation early in algebra, and
so this is not a problem. We can then look at the structure of the
statements without worrying about the usually irrelevant meaning of
the variables involved.


>> It is necessary to let the user invent notation, if necessary, and
>> for the language and compiler to help, not hinder.


>The user can invent notation in most computer languages. The question
>is not whether or not they can invent notation, but in what fashion
>they will be allowed to invent that notation and what safeguards there
>are in the language design to insure that they are clearly documented
>as being invented notations as opposed to intrinsic ones.


A few languages allow the introduction of new types, but do not allow
them to be called types. There were older languages which did. And
introducing functions is not the same as introducing operators.
Fortran compilers did optimizations at compile time for the power
operator which become far more expensive if attempted at run time; the
compiler is highly branched already, as it has to parse. Also,
functions must be in prenex form, while operators can be in any order.
--
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
hrubin@stat.purdue.edu Phone: (317)494-6054 FAX: (317)494-0558
--

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