Re: Definable operators

Ephram Cohen <ephram@ear.Psych.Berkeley.EDU> writes:


> What about including the other punctuation
> characters that are not used in a given language as available for
> definition. Technical issues aside (I know this can be ugly) I think
> that this scheme has some merit. A heirarchy can be defined for
> precedence of operator that stays with the language.
>
> It seems to me that the benifit of syntactic sugar in terms of
> readability of code is immense.


Sure thing. To maintain readability, I'd suggest you try insisting on
some syntax that a routine using the reserved punctuation must use to
denote its meaning, and make it easy enough to use that you can
encourage, perhaps even require, its use outside of hidden modules.


For example, given a small C-like subset without bit operators, one
might be able to use ^ for whatever one wants, but to do so, one would
have to do something like:


foo (...)
{
    (int) ^(int, int): see_module bit_operations;
    (int) |(int, int): see_module bit_operations;
    (int) &(int, int): see_module bit_operations;


    ... a & b ... /* et cetera */
}


Not a perfect solution, but at least the reader of the code sees that
these reserved lexemes are defined to mean something, and knows where
to look up their meanings. (I chose verbose names on purpose, since
#include wouldn't make sense there, and C doesn't have Fortran's
`USE', etc.)


In a sense, this just represents the linguistically useful counterpart
to C++'s (and Fortran's) laundry-list approach to modules, to wit,
that a module contains a laundry list of things it does, types it
supports, operators it defines, and any code that references the
module therefore automatically is written in a language as extended by
that module.


I'm suggesting the automatic extension not be provided, and that,
instead, the referencing module must make explicit mention of
linguistic features it's using and which module(s) provide those
features in their laundry list.


You could certainly extend such a scheme to accommodate introducing
precedence, etc. In fact, think of it as a kind of miniature, limited
`yacc' source file -- kind of a scary thought, but at least you can
pat yourself on the back knowing that you've made _authors_ of code
specify the extended grammars they want to use so that _readers_ of
the code will see it without having to thumb through tons of other
modules' laundry lists.


And, making programmers who want nifty syntactic shortcuts (that often
make code less readable) actually specify the grammar for their
shortcut in each function where they use it will not only improve the
overall readability of the code, but it might actually dissuade them
from bothering with their shortcuts, and actually write the clearer
version in the first place.


If you try the above, you basically can't offer textual inclusion
facilities like #include, or you risk their being used as work-
arounds for your "strange requirements". You can still provide many
of the advantages of them in a facility that acts much like textual
inclusion, but treats the equivalent of a .h file that starts out with


(int) ^(int a, int b): xor(a, b);
(int) |(int a, int b): or(a, b);
(int) &(int a, int b): and(a, b);
...


as defining those operators for *only* the expressions that actually
appear in *that file*. That is, the above statements in a
bit_operations.h file would apply only to the code actually written in
that file, but would have no effect on the code in another file that
did an #include (or `see_module') of bit_operations.h.


So, such a module definition would perhaps extend the language of its
users such that they could access xor(), or(), and and() without
specially calling them out (though, given my experience in the Fortran
world, I'm not sure that's such a good idea!), but they would _not_ be
able to use ^, |,and & without themselves explicitly defining the
syntax (as shown at the top of this post).


This is basically just like math papers that define their invented
notations before listing lots of equations using them.


The only "new" thing about the above is that I'm actually suggesting
programmers be made to define their invented notations as well,
i.e. to say what they mean, not just type a short-hand magical
incanation (such as "#include <bit_operations.h>") that changes the
language of the code that follows it to something entirely different,
thus leaving it to the readers to figure out which magical
incantations makes which changes to which parts of the language, each
of whom has to reverse-engineer what the author of the code originally
knew but didn't feel like writing down at the time (or had no elegant
way of doing so).


--
James Craig Burley, Software Craftsperson burley@gnu.ai.mit.edu
--

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