Re: Need input on designing a new language

Ray Klefstad II <klefstad@opera.ICS.UCI.EDU>
Mon, 4 Jun 90 04:45:26 GMT

          From comp.compilers

Related articles
Need input on designing a new language ramsey@ncoast.ORG (1990-05-26)
Re: Need input on designing a new language henry@zoo.toronto.edu (1990-06-01)
Re: Need input on designing a new language klefstad@opera.ICS.UCI.EDU (Ray Klefstad II) (1990-06-04)
Re: Need input on designing a new language henry@zoo.toronto.edu (1990-06-04)
Re: Need input on designing a new language praxis!itcp@relay.EU.net (Tom Parke) (1990-06-06)
| List of all articles for this month |

Newsgroups: comp.compilers
From: Ray Klefstad II <klefstad@opera.ICS.UCI.EDU>
Date: Mon, 4 Jun 90 04:45:26 GMT
Organization: UC Irvine Department of ICS
Keywords: design

>>Thats the heart of my problem, simple to implement. It would be easier for
>>me if I forced the user, programmer, to declare all the procedures before
>>the function body occurs...
>
>You have to decide where your priorities lie: ...


It is really more complex than that. There are (at least) four issues one
must consider when designing a general purpose language:
        1) programming ease
        2) compiler speed
        3) ease of compiler implementation
        4) language support for good software engineering


Let's look at three alternatives for subprogram declaration:


A) requiring specification before declaration of every subprogram
B) requiring specification before use of every subprogram
C) allowing arbitrary declaration and use order (use before declaration
      is ok)


This is how I would grade each approach on each issue (scale: excellent,
good, fair, poor, fail):
        Approach A:
                1: poor (requires duplicate typing of specs and bodies)
                2: poor (one pass, but must process duplicate definitions)
                3: good (almost excellent, but B is just as easy)
                4: (possibly) good (if you allow separate module specs and bodies
                        like Ada or Modula 2 and separate compilation with strong
                        semantic analysis across modules)
        Approach B:
                1: good (usually only a few forward declarations are necessary,
                      but this style may force a backwards order on declaration,
                      i.e., main subprograms must be places before their auxiliary
                      subprograms)
                2: excellent (allows one pass with minimal duplicate definition)
                3: excellent (specs are always known before a use - even in one pass)
                4: (possibly) excellent (same as Approach A.4 above)
        Approach C:
                1: excellent (what could be easier)
                2: poor (This will require two passes in the front-end. I can
                      think of one way to do it in one, but it will require lots of
                      space and time overhead.)
                3: fair (again, requires two passes or some other complicated scheme)
                4: poor (How do you get semantic checking across modules?
                      An optional pass by a lint-like program? Yuck!)


I say approach B is the winner. This is what you see in current
languages such as Pascal, C, and even Ada. I think the design of Ada
packages with separate specs and bodies is a real winner on this issue.
The subprogram specs in the package spec act as forward declarations
for the subprogram bodies in the package body and as forward declarations
for all modules that use (via `with') the subprograms defined for use by
that package. In addition, you get excellent support for the often
overlooked point 4.


You asked for opinions about forward declarations and I gave it. You
didn't ask for opinions about your decision to invent and implement a
new programming language, but I will give mine anyway.


If your motivation is to learn something about programming language
implementation, then it's a good idea. If your motivation is to invent
yet-another-programming-language, then I predict NO ONE will ever use
your language. You will probably not use it either - even if it
incorporates a few new and interesting ideas! Look at the
history of languages such as Alphard, Euclid, (even Smalltalk to some
extent) - the list goes on - and these are languages that had significant
interesting ideas. Look what languages are successful: FORTRAN, COBOL,
BASIC, C, Ada, and (based on initial reaction) C++.


Ada was successful (if you can call it that) due to tremendous financial
and political support from the Dept. of Defense. C gained support (over
assembly, FORTRAN, etc) because it is easy for programmers to write
efficient code (even with a non-optimizing compiler which is very easy
to write), it is easy to do machine-oriented operations, and it is easy
to implement (or port) a C compiler. C++ is riding on the success wave
of C. Few programmers want to expend the effort to learn a new language
(such as yours), but they might learn a few additions to their favorite
language. While I do not favor programming in Ada, I have to admit
it has the best design of all the languages with which I am familiar,
but I doubt Ada would have succeeded without the support of the U.S. DOD.


A better use of your time would be to make a small improvement to an
existing language (such as that done by adding classes to C in C++).
Perhaps you can figure out a new multi-tasking model or an exception
handling model that works well with object-oriented languages. This
could be added to implementations of C++, Objective-C, Smalltalk, and
others (perhaps even Ada). When you do so, give it a nice syntax that
blends in with the conventions of the language you are extending.


One more thing to consider is the purpose of your language. Who will
use it? What will be its strengths? Will it be the language to replace
all other languages? You must decide, because you must make numerous
design decisions (tradeoffs considered) between various ways to handle
features of programming languages. Are you going to build a debugger
and tools to support software development in your language? Are you
going to write language primers to teach programmers to use your
language? If not, then who will?


I don't mean to squelch your enthusiasm, but you should know what you
are in for. I certainly don't want to discourage experimentation and
learning, but be aware of what is in store if you are expecting others
to use your language. I can tell you, I already don't like the syntax
you have shown in your examples, but that is probably just personal
preference. Many did not like Ada when it first came out. It's always
easier to learn a language if it is consistent with a language you
already know, then you can learn just the differences.


If you are interested in designing languages, I suggest you first read
"Programming Language Concepts" by Carlo Ghezzi and Mehdi Jazayeri
or some other appropriate text covering language issues and design.


So do I design new language features? Of course I do. It is loads of
fun. I am lucky to teach the compiler courses here at U.C. Irvine and
each term I must come up with a new language for my students to
compile. I often try out new ideas in this course, but I usually do so
by starting with a subset of Ada and adding one new interesting idea.
--


Post a followup to this message

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