Review of existing HLLs


Preliminary Note

There are a lot of these, ain't it ?
I'd love feedback from you, particularly if you know any interesting language not (or poorly) considered here...
Also feel free (=bound :-) to add your comments and to correct mistypes/broken english.


Contents

  • Existing languages
  • A new HLL



    Existing languages


    C/C++

    Description
    "C" is a low-level, weakly typed, static, non-modular, non-generic, non-reflective language. The *only* positive point about it is that it is the one standard as a programming language.
    Note that "C" offers no particular interest when cut from all its standard libraries, for you can no more port existing software. As Tunes won't implement any standard "C" library (at least as support for native code), because its semantics is so much different, "C" offers no interest on top of Tunes.
    Thus, "C" just has nothing to do with Tunes, except perhaps as a layer between Tunes and a POSIX compliant system, if Tunes is to be implemented as an application under such system.
    "C++" is the same, with a huge amount of horrible kludges hopelessly added to cope with "C"'s lameness. But it's still have the same fondamental misfeatures as "C".

    There are lots of books about C and C++. About C, get the C Bible by Kernighan&Ritchie (the original authors). About C++, just shoot(yourself.foot++).
    Look on prep.ai.mit.edu or any mirror site to find GCC, (GNU C Compiler), a free C/C++ compiler, and a lot of utilities written in C. Here are papers about why not use C or C++ in general. This one is particularly meaningful as to what a language should be (that C/C++ is not).


    Pros
    1. Anybody knows this language, and we wouldn't have to readapt to another language syntax, as it is the one (now ANSI) standard in system programming (yuck).
    2. We may test programs immediately, without having to wait for the kernel to be done.
    Cons
    Actually, C and C++ are not high-level languages, and just worth throwing to nearest garbage can (poor garbage can), unless you're stuck to it, which you are on existing systems (themselves worth as much, but again, you're stuck to them until Tunes comes out).
    1. C/C++ do not include functions as a first-class object, thus creating a boundary between using and programming: it's a static language; you can't both program and use at the same time. That's the opposite of user programmer/user friendliness.
    2. C/C++ is not a structured language: procedures are all global; that's why C/C++ will NEVER allow having independent light threads, and why it's impossible to have a lightweight multitasking system under C/C++. You may notice that this point is related to the preceding remark: if procedure were objects, you could include them individually inside thread objects, then each thread would have its own independent code.
    3. C/C++ know only early binding (i.e., it only compiles directly executable code), hardly knows about dynamic library linking (that's not a language transparent feature; only a linker feature); C/C++ considers a program to be complete, finished, and run in the absolute without interaction with other programs, but through the system; that's why all ROI in C must be explicitly done through system calls !!!
    4. The "we won't have to rewrite a compiler" argument doesn't stand: if the system is to be OOed, we'll have to adapt the compiler so as it produces OO code compliant to our system's requirements. Unless our system brings nothing that can't be done easily by replacing the standard library, that's impossible; so only front ends can be reused, which are trivial to write.
    5. As it's a low-level language, either we'll have to have low-level specs for the OS (as with Unix), so that we can't adapt to an architecture different from that for the which the OS was designed; or we'll have to rewrite a great amount of the C/C++ code on each system adaptation. So we lose either system functionality, or language portability. Interoperability of code is also impossible, unless we define a common target architecture that other computers will have to emulate.
    6. For the same reason (C/C++ being low-level), we can never achieve object-level security, but by having a C/C++ program for each object, which either disallows everything -however little- is an object in the system, or requires many a low-level system (as opposed to language) declaration in a C source, and/or requires having tiny C/C++ programs, which contradicts the heavy compilation cost and the class philosophy of the language.
    7. The C++ philosophy contradicts the idea of late user-object binding. C++ knows only of early compile-time object binding, or at best/worst binding with compile-time defined virtual class realization through virtual tables. So to make the slightiest add/change, you must recompile the whole app.
    8. The C++ preprocessor allows simple macro-definitions, but neither macro instructions, nor recursive macro definitions. If #define DEF #define was possible, for example, it would be possible to Ziv-Lempel compress a source program from C to C. But cpp just plain sucks.


    Ellie

    Description
    Ellie is a language designed for computer-scheduled parallelism, which stresses the existence of future values, that the system may lazily or concurrently evaluate.
    You may find papers about it here

    Pros
    1. It has unified semantics for objects (code&data)
    2. the same for parallelism
    3. it has already been studied
    Cons
    1. it's got a cryptic syntax
    2. it's not standard and we don't own it; a compiler may be difficult to have.
    3. It's got almost no "no". No negation, exclusion and such, but in the function/operation assertion, so the compiler cannot understand things as simple as "this object can take these value, and NO other.
    4. no exceptions to cope with the previous: these would be useful for handling errors or special cases, but would be very difficult to design consistently with parallelism.



    A new HLL

    Pros and Cons

    Pros
    1. We can design the syntax to fit our needs and ideas, so that it's much easier to use. Moreover, even C isn't our natural language, and whatever language we use, there will have been adaptating time to use it.
    2. We can correct the lacks of any existing language we would have used.
    3. Portability: both the system and the language may be as easy to port. All you need do is porting a LLL compiler back-end or interpreter, and hardware specific lolos (low-level objects).
    4. The language is perfectly well adapted to the system. No need of bizarre and slow language -> system call translation.
    being efficient as an interpreted language, it may serve as a shell language as well as a programming language; being powerful, and easy to specialize via standard libraries, it also replaces small utility languages (sed, awk, perl, etc); finally, being high-level and knowing of relations between objects, it is easily adaptated to an AI language. So there is no more need to learn a different language for every application; the same language is used for (almost) everything; no more need to learn new syntaxes each time.
    Cons
    1. we have to relearn a new language syntax. But as we may choose whatever syntax pleases us (and support multiple automatically translatable syntax), this is no great deal, really.
    2. No existing compiler can be used directly. This is no great deal either: Front end are easy to write, and no existing back end can fit an interestingly new OS' object format, calling conventions, and security requirements. Moreover, our system having a brand new conception, even with a traditional language, we'll have to learn restrictions about our way of programming.
    3. we have to debug the language specifications as we use it. But this can prove useful to refine the language and the system specs. Here is an interesting point.


    To Do on this page

  • Find all existing HLLs.
  • Write a summary about each of these, with particularities, pros, cons, pointers, (examples/history ?), etc.
  • Add references to the Glossary.
  • Wait for feedback and criticism.


    Back to the Tunes HLL Subproject.


    Page Maintainer:
    Faré -- rideau@clipper.ens.fr