Re: Pronouns in programming language?

The moderator mentioned that
<< Cobol lets you elide comparison operands, something like
IF FOO-BAR LESS THAN 12 OR GREATER THAN 42 THEN ...
>>


COBOL also has condition names which in effect allow elision of
subject field name and relational! The condition name feature includes
ranges and list of values. You can code something like


    IF condition-name ...


That facility requires one specification of the condition in a
declaration of the condition name, and then permits numerous
references to it by its mere name. (This creates some challenges for
grammar writers when parsing things like


    IF A = B AND C ...


where C could be an implied object of the relational condition like
A=C or it could be a condition name. ((By the way COBOL has a
tradition of calling the front and back parts of relational expression
the subject and object)).


COBOL also definitely allows suppression of the subject of relational
expressions in its case constructed, the EVALUATE statement (added in
COBOL '85). Simplest use of this implies the equality relational. Yet,
also, the surface of the cases can have significant topology which is
projected by the header of the EVALUATE statement, each case (the WHEN
clauses) can even variably suppress nodes in that topology with an
'ANY' token. ((Thus it is not a lexical portion of a relational
expression that is elided, but insted that whole relation in the
mix. EVALUATE topologies are actually all logical AND surfaces,
expressed with an 'ALSO' token.)) The 'ANY' token can be used the
otherway around too; implying a nondescript node in the topology when
used in the header, leaving the cases to list out the full relation
subject+relop+object, or dummying in 'TRUE' (yet another way to
nullify a node in the topology!).


With any interest in implied subjects or objects, you might want to
study the history of the rules for the attribution of NOT in implicit
conditional expressions in COBOL. For example, in


    IF NOT A = B AND C


this leads to what you might call DeMorgans nightmare (two nights in a
row since C could be a variable or a condition name!). And if I
remember the history (assuming C is a variable), the expression


    IF A NOT = B OR C ...


might have had different semantics at times. (EVALUATE never gets
into this trouble... A.F.A.I.K.)


So if you are going to imply some subjects in anything you develop,
beware of the potential problems with negation or inversion. In a way
(a way that I have not thought out too completely) the problem here is
partly precedence. COBOLers are not much interested in precedence, so
the language standard has tried to glide in the path of 'what would it
mean in natural language?', (quite an undertaking for a multinational
committee).


Partly also this later problem is sourced in the fact that the chunk
of language that goes by the spelling N-O-T participates in
not-relationals and not-if-conditionals. Languages like C avoid this
by lexical props (evolved partly accidentally, and partly
intentionally). We can see that the tilde (~) and the exclamation
point (!) have different functions. Less obvious, but just as
important, digraphs like exclamation point + equal (!=) are actually
lexically distinct from simple exclamation point (!). Let me
illustrate this


      ~var_int /* produces binary inverse */
      !var_int /* evals the NOT of evaluated var */
        var_int != 0 /* a specific relation, NOT EQUAL */


If you try to implement a language that implies subjects (by means of
pronouns of elision), then you may wish to figure how the nots will be
applied. Distinct lexical matter to mark distinct kinds of negative
logic is helpful, but in a modern context the idea implied operands
with negative logical indications must be worked out with your plan
for precedence. And it must be clear to the coder what it will mean.


Best Wishes,


Robert Rayhawk
RKRayhawk@aol.com

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