Conference turris::languages

VAX PASCAL invented the concept of "semi-reserved words" to handle this
situation.  Usually a semi-reserved word had a special, built-in,
compiler-defined meaning.  However, if the user defined an identifier
with a spelling identical to a semi-reserved word then (1) a warning
was generated, (2) the identifier was given its new definition, and
(3) the semi-reserved word no longer had its special, built-in meaning
(outside the scope of the identifier with the same spelling, the semi-reserved
word kept its built-in meaning).

Example of semi-reserved words are OTHERWISE, REM, VALUE and MODULE.

The concept of semi-reserved words allows VAX PASCAL to compile standards
conforming programs that use identifiers spelled the same as reserved words
introduced by VAX PASCAL extentions.  It also means the addition of semi-
reserved words in future product releases will no invalidate customer programs
designed for earlier releases.

Note:  BLISS-11 from CMU allowed any reserved word to be redefined as
a user identifier (it was often necessary to use $QUOTE to do this).  This
feature was required when BLISS-11 was updated to include the co-routine
feature of BLISS-10 which used LENGTH as a reserved word.  Too many earlier
BLISS-11 programs used LENGTH as an identifier so allowing reserved words
to be redeclared kept these older programs running.  Of course, any program
that used LENGTH as a user identifier had limited use of the co-routine facility
in the scope of that identifier.  Digital dropped the ability to redeclare
reserved words when it defined BLISS-16 and the other common BLISSes.

    In TPU, we've defined numerous new keywords in our up-coming version.
    They have unusual names like "LEFT", etc.
    
    We're getting around this problem by letting locals variables (but
    not globals) occlude keywords and builtins.  Our compiler will generate
    an informational message, so those users who care can rename the
    preempted variables.
    
    	- Barry

   I'd like to see languages use the notion of a "vocabulary level".  A given
   module would have a declaration saying "the following code unit uses the
   builtin vocabulary published with standard #X, or release #X".  Then for
   recompilation of old code I would not have to put up with compiler warning
   messages and I wouldn't have to change the source.

   Paul Clark

    You could just use PL/I - there aren't ANY reserved words (and your
    example is one of the reasons why.)  On the other hand, it does make
    it possible for people to write very unmaintainable code...  (Just
    because the compiler's parser can get it right doesn't mean that someone
    trying to read the code can...)

	declare (if,then,else) entry(entry) returns(entry);
				/* Declares the functions "if", "then" and
				   "else" */
	if if=if(if)
	then
	    if(else)=then(else);
	else
	    else(if(then))=then(else(if(then)));

    Kent Glossop
    VAX PL/I    

    FORTRAN has no reserved words either.  At the other extreme, Ada
    has reserved words, but no implementation is allowed to add to the
    list.
    				Steve

    C also has reserved words.  The standard does not allow you to
    extend the list.  Did that stop us?  No way.  We added: 
    
    	globaldef
    	globalref
    	globalvalue
    	readonly
    	noshare
    	variant_struct
    	variant_union
    
    We did, however, eliminate the reserved word "entry".  It was in the
    list in Kernighan and Ritchie (the "standard" of the time), but the
    language didn't use it -- it was "reserved for future use". 
    
    It wouldn't be so bad if we documented our changes.  The last two in
    the list above (variant_*) were only recently documented in the
    release notes for 2.3 but have been there since 2.0 (perhaps their
    complete lack of utility had something to do with the lack of
    documentation :-). 

    Who knows what other reserved words are lying there waiting to
    trip up unsuspecting customers (and not just in C)?
    
    To be fair, the C standard didn't exist at the time the compiler was
    written and is still only in draft form.  The DEC extentions dealing
    with storage classes are actually even useful (some of which are now
    in the standard, albeit in an incompatable syntax to what we did).
    
    	Steve Glaser
    

    Fortran (old ones at least) even allowed you to run everything
    together without spaces.  The compiler didn't know the statement
    
    	DO10I=1,100

    was a loop until it hit the comma.  Until the comma everything
    looked like an assignment statement.
    
    steveg

Re: 123
>    C also has reserved words.  The standard does not allow you to
>    extend the list.

Do you have a quote for that?  My copy of the draft standard (July 1986)
even contains suggested common extensions: asm, entry, fortran...

Re .6:

>... (perhaps their complete lack of utility had something to do with the
>lack of documentation :-).

The following is just as true today as it was yesterday:
				/AHM

                     <<< TLE::PUBD$:[VAXNOTES]VAXC.NOTE;1 >>>
                                -< VAX C Notes >-
================================================================================
Note 638.4                     variant aggregates                         4 of 5
NOBUGS::AMARTIN "Alan H. Martin"                     13 lines  20-JAN-1987 20:00
                  -< Real Programmers use them all the time >-
--------------------------------------------------------------------------------

Re .1:

>    Not only are they of extremely limited utility, ...

The functionality provided by variant_union and variant_struct was vital in
the construction of discriminated union datatypes for a highly optimizing C
compiler I worked on last fiscal year. Given the same problems to be
solved, I'd use the same approach today.

If they weren't invented when they were, we would have asked for them
anyhow.  All things considered, we might just have added something like
them ourselves to VAX C if they hadn't happened along for free in V2.0.
				/AHM

        Re: .7
        
        Ah, yes, one of my all time favorite Fortran user errors. A long
        time ago in a galaxy far far away, I was a student at a CDC site,
        where we actually used CARDS and KEYPUNCHES for programming! I
        worked at the consultants desk, and someone came up with a program
        tha wasn't working. Due to poor quality printout (worn ribbon and
        hammers) it took us a long tome to notice the statement: 
        
        	DO 10 I = 1.10
        
        had a period where the comma should be. We couldn't figure out
        what was going on, or why the compiler didn't flag the statement
        as bad, until in the variable map, we found DO10I was defined. I'm
        sure I'll never forget this one. 
        
        Fortran seems perfectly happy to let you have arrays called DATA,
        variables called IF, etc. About the only thing that can trip it up
        is use of FORMAT as an array name. 

Re .10:

>About the only thing that can trip it up is use of FORMAT as an array name. 

Two FORTRAN compilers beg to differ:

On VMS:

$ ty x.for
	INTEGER FORMAT(2)
	I1 = 1
	I2 = 2
	I6 = 6
10	FORMAT(I1) = -100
20	FORMAT(I2) = -200
	WRITE(5,30) FORMAT
30	FORMAT(I5)
	END
$ fortran x
$ link x
$ run x
-100
-200
$

On TOPS-20:

@exec x.for
FORTRAN: X
MAIN. 	
LINK:	Loading
[LNKXCT	X execution]
-100
-200
CPU time 0.18   Elapsed time 0.97
@

    Re .10:
    
    Software Engineering Note #13 has a list of significant 
    software/hardware/etc bugs which have been covered in various 
    publications, some of which are somewhat familiar to the general
    public.  (I presume the list was pulled off the usenet.)
    
    One entry --
    
    Mariner 1: Atlas booster launch failure DO 100 I=1.10 (not 1,10)

    I wonder how much mischief this one problem (the invisibility of
    the difference between "," and "." on most primitive printing hardware)
    has caused.
        
    							Ralph      

        Re: .11
        
        All right, I guess I got it wrong. After further thought, I think
        it is a function or subroutine named FORMAT that may confuse SOME
        Fortran compilers. 

Re .13:

I guess those implementations have bugs in them, then.  I can't think of
how subroutine names could appear in the same context as the keyword
FORMAT. And the only place I can think of a function name doing so is in
the definition of a statement function.  The occurrence of an "=" following
the first outermost set of parens is sufficient to distinguish the two cases.

Someone showed me a confusing example of FORMAT in college, but it relied
upon a Hollerith constant 3H)=( in the format, or something like that,
and in retrospect I don't think it was actually ambiguous.

One of my favorite user errors is:

	DOUBLE PRECISIONS X,Y

which declared two DP variables, SX and Y.

Striking somewhat closer to home, I leave it as an exercise to the reader
to determine whether the statement:

	INTEGERFUNCTIONF

means

	INTEGER FUNCTION F

or

	INTEGER FUNCTIONF

in VAX Fortran, which supports long identifiers.
				/AHM

    The only source restriction on "reserved words" I can
    think of in FORTRAN is that the ENDFILE statement must have the
    word "ENDFILE" all on one line.
				Steve

Re .15:

You came close, Steve.  The restriction is only that you can not choose
to put the "D" and "F" of ENDFILE on separate line (lines, hell, lets
call them card images like they really are!).  Thus,
       E
      1N
      2D    F
      3I
      4L
      5E

is OK.

Subscripted FORMAT causes a problem for compilers that try to accept
old FORTRAN II syntax as well as FORTRAN-66 and FORTRAN-77.

Consider:
100	FORMAT(X5H)=A(5)

In FORTRAN II this can only be a FORMAT statement.  In FORTRAN-66 and
FORTRAN-77 it can only be an assignment statement (or statement function
definition).  Although VAX FORTRAN does accept FORTRAN II syntax FORMATs,
in this situation it breaks the ambiguity by following FORTRAN-77 and
making this an assignment statement.

Re .17:

A-HAH!

Yep, that's what I was thinking of.
				/AHM/THX

re .14

>>...I leave it as an exercise to the reader to determine whether the statement:
>>
>>	INTEGERFUNCTIONF
>> means 
>>	INTEGER FUNCTION F
>> or 
>>	INTEGER FUNCTIONF
>>
>>in VAX Fortran, which supports long identifiers.
>>				/AHM

Alan,
    It's been three more years since I was implementing a FORTRAN compiler
than it's been since you were.  If I remember my parser generator correctly,
a FUNCTION with no arguments must have a pair of parentheses (()) after the
name of the function.  I opt for number two.  Is that a correct analysis?
I know I could just ask the VAX FORTRAN compiler, but to do that I'd have
to find (and perhaps install) one here in ULTRIXland.
--Joe

I don't have a standard handy, but I think you are thinking of function
*invocations* requiring the empty parens.  I think that declarations
may omit them with impunity according to the standard.  VAX Fortran
certainly lapped it up with no problems just now.
				/AHM

    What we did for Fortran-10/20 is what VAX Fortran does.  For:
    
    	INTEGERFUNCTIONF
    	INTEGERFUNCTIONF
    	END
    
    it compiles without error.  The first statement declares a function
    named F.  The 2nd a variable named FUNCTIONF.  You can tell whether
    you had a beginning PROGRAM/FUNCTION/SUBROUTINE/DATA statement and
    from that its either a function or variable declaration.

    For PL/I, the archetypical silly statement is something like:
    
    if then = else
    then else = if;
    else if = then;
    
    That works fine, provided that if, then and else are of types which
    can be converted to each other, and either all scalar or are all
    arrays of conforming dimension.  If you don't mind warnings, you
    don't even have to declare them.
    
    The example given in .4 included two excerpts which were invalid PL/I.
    Both have the same problem; the simpler one is given below. 
    
        if (else) = then (else);
    
    Given that "if" is neither an array, nor builtin pseudo-variable, but
    instead is a function, the presence of an argument list makes this an
    expression, and expressions are not permitted to the left of the
    assignment operator.  Only references are permitted, although
    references can contain expressions as subscripts, certain parameters of
    pseudo-variables, or preceding a pointer qualifier ("->").
    
    The designers of PL/I got around having reserved words by reserving
    all the simple and compound delimiters, and basing the syntax on
    the delimiters.
    
    In COBOL, the archetypical silly statement was mildly obscene. I'm not
    sure whether including it in this notesfile would violate Digital
    policy. The expurgated statement below is a looping subroutine call. 
    
        PERFORM LABEL1 THROUGH LABEL2
            VARYING VARIABLE1 FROM 1 TO 12
            UNTIL VARIABLE2.
    
    The substitutions are left as an exercise to the reader.
    
    Spencer Love
    File Storage Architecture

    RE: .22

    [Blush] Right.  I must have been working too hard (on PL/I V3 features)
    at the time to make such an obvious error...

The language/compiler our group uses for implementation is DECWRL Modula-2.

It raises some interesting issues about this topic.

Capitalization of reserved words and standard/built-in identifiers is not
forced (the default is to allow each identifier in any combination of case),
until you tell the compiler to do this. For example,

END = end = End

But, for user-defined identifiers, the compiler *is* case-sensitive.

Unfortunately, some modula-2 programs take advantage of the fact that this is
non-standard behavior, and create variables with the same name as a reserved
identifier.

A reserved word can not be used as a user-defined identifier unless you turn
the standard-case switch on (and the user-defined identifier isn't all in
upper-case). A built-in or standard identifier can sometimes be redefined. For
example, if you have to import it, you can define/import your own identifier
of the same name.

Finally, this compiler adds many reserved words. These are set off from the
standard reserved words by adding a prefix character of '@' (e.g. @align,
@size, @inline, @dynarray ...). Other compilers add non-standard keywords with
the prefix '%'.

Chuck