Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!usc!snorkelwacker!spdcc!esegue!compilers-sender From: klefstad@opera.ICS.UCI.EDU (Ray Klefstad II) Newsgroups: comp.compilers Subject: Re: Need input on designing a new language Keywords: design Message-ID: <1990Jun4.044526.14926@esegue.segue.boston.ma.us> Date: 4 Jun 90 04:45:26 GMT Sender: compilers-sender@esegue.segue.boston.ma.us Reply-To: Ray Klefstad II Organization: UC Irvine Department of ICS Lines: 120 Approved: compilers@esegue.segue.boston.ma.us >>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. -- Send compilers articles to compilers@esegue.segue.boston.ma.us {spdcc | ima | lotus}!esegue. Meta-mail to compilers-request@esegue. Please send responses to the author of the message, not the poster.