Language design

preston@helena.rice.edu (Preston Briggs) writes:
>At any rate, the local lore is that compiler writers should _not_ design
>languages. Instead, they should be confined to tiny cages and forced to
>implement the language as specified, dammit. Sort of a corollary of the
>old adage "give them an inch, they'll take a mile".


I disagree, somewhat. The crucial point is that compiler writers must
not be allowed to design the language AFTER it has been specified.


BEFORE it is specified, if the people designing the language have any
inclination towards designing an "efficiently executed" language, then
compiler-writers had better be involved. They can offer advice about


(1) what to add/subtract to make the language more optimizable.


(2) what can be added/subtracted without cost.


(3) what features can share costs (given that X is in the language, it
        costs little or nothing to add Y).


(4) whether a feature must be "paid for" all the time, or only if it
        is used.


In addition, compiler writers make dandy devil's advocates for
language specifiers.


If I were designing a new language, I'd pay a tremendous amount of
attention to recent and not-so-recent work in type theory and type
inference. See William Cook's work, Luca Cardelli's work, and scan
through the SIGPLAN PLDI proceedings back through about 1988.




(Anecdotes follow for sake of concreteness -- this is based on my
experience as compiler-writer-but-not-on-the-committee for the design
of Modula-3.)


When Modula-3 was designed, I fought hard (from the peanut gallery)
for multi-dimensional open arrays, arguing that


(1) this feature makes the language more useful, especially for
        numerical codes;


(2) given reduction-in-strength and loop-invariant code motion,
        we can do a good job compiling it;


(3) (a compromise) if we restrict our "subarrays" to the top-level
        only (i.e., no chance of taking a submatrix, a pity), then the
        one-dimensional open case works just as well as it ever did;
        the only question remaining is whether the multidimensional case
        should be illegal, or "slow" (slow relative to what?)


A battle that I lost was for first-class functions and first-class
methods -- my arguments in favor of them were


(1) we know how to optimize these in many common cases (see the Scheme,
        Orbit, and S1 Common Lisp papers);


(2) the language already has garbage collection, exceptions, and
        threads; thus, most of the run-time machinery required to
        support first-class functions is already present.


In hindsight, one thing that I should have pushed for was the idea of
unaliased (by reference or value-result) parameters (by special
declaration, if necessary); this is good because it is an optimization
enabler (better for dependence analysis), compiler-checked documentation,
and a good tool for helping to ensure that remote execution will work.
Note that the "compiler writer" contribution here is not the only reason
this should have been in the language, but it is a good reason.


As a devil's advocate, I pointed out that shared variables might not
behave as some people expected. According to the spec (and my
pathological imagination), the code


    WHILE shared_variable = 0 DO END;


could (and would, by general-purpose optimization algorithms) be optimized
at least to the form


    register := shared_variable;
    WHILE (register = 0) DO END;


and could quite likely be compiled to


    IF shared_variable = 0 THEN
          LOOP (* forever *) END;
    END;


(Note that the goodness or badness of this transformation is not the
issue; rather, I am only pointing out that the spec as written permits
this. If this is bad, this indicates that the spec should be changed.)


This is allowed because, in the absence of the use of the Thread
interface, reads from a variable written by another thread see "an
implementation-dependent value of its type". Given that globals will be
loaded into registers whenever possible (for efficiency) one legal value
is the old one. (An implication of this is that calls to procedures must
be treated as touching all global variables, since (lacking other info) a
Thread routine might get called.)


David Chase
Sun
--

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