The Coq distribution
includes full docs.
Perl
Perl
is a scripting language
for easily manipulating text, files, and processes.
It provides easy ways to do many jobs
that were formerly accomplished (with difficulty)
by programming in C or one of the shells.
And here's a
Perl 5 page
for people on the bleeding edge.
SELF
SELF
is a Object-Oriented programming language
based on very simple concepts which allow efficient implementations.
Dylan
Apple and CMU develop
Dylan,
an object-oriented dynamic language to replace C++,
whose semantics is like a good OO LISP,
but without the horrible S-exp syntax.
BETA
BETA
is an OO language from those who invented SIMULA.
Its only current implementation is commercial, it is
the Mjolner BETA system.
Napier88
Napier88
is a persistent programming system from University of St Andrews
Arjuna
Arjuna
is allegedly THE programming system for reliable distributed computing.
Being developped by (and freely available from)
the Arjuna project team,
The Department of Computing Science,
The University,
Newcastle upon Tyne,
NE1 7RU, UK
FORTH
The FIG (Forth Interest Group) homepage,
An online book,
"Real-Time Forth"
Sather
Sather
is a free Object-Oriented programming language rival of Eiffel.
CECIL
The Cecil
is an OO language from the same who invented SELF, at University of Washington.
ML
ML is a functional language.
SML/NJ
and
CAML-Light
Scheme
Scheme is a small dialect (some say a skimmed version) of
the LISP language.
Scheme has got a
WWW page
at the MIT, and
you can find more info about Scheme in the Scheme FAQ,
from the
comp.lang.scheme newsgroup.
The Scheme Underground
project to build a complete computing system on
top of Scheme48, a portable implementation of
Scheme.
Scheme
Object-Oriented systems have been implemented in Scheme:
OScheme
Objective Scheme from INRIA
Moostrap
(a Self-like language with behavioral reflection)
Ken Dickey's
YASOS
(Yet Another Scheme Object System)
Python
Python
is an OO programming language
Oberon
Oberon
is the latest modular OO language by Niclaus Wirth
(the author of Pascal and Modula).
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.
References
You may find papers about it
here
Pros
- It has unified semantics for objects (code&data)
- the same for parallelism
- it has already been studied
Cons
- it's got a cryptic syntax
- it's not standard and we don't own it;
a compiler may be difficult to have.
- 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.
- 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.
RPL
RPL ("Reverse Polish LISP") is the language from HP 28/48 calculators.
Despite their lack of horsepower, these calculators are much more
usable and friendly than my unix workstation, because code IS an
object as anything on the HP...
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".
References
There are lots of books about C and C++.
About C, get the C Bible by Kernighan&Ritchie (the original authors);
there's also an online tutorial by Dave Marshall,
Programming in C.
About C++, just shoot(yourself.foot++);
or if you must, learn to program C++ with the
Globewide Network Academy's (GNA)
Introduction to Object Oriented Programming Using C++.
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
- 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).
- 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).
- 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.
- 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.
- 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 !!!
- 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.
- 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.
- 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.
- 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.
- 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.
Common LISP
Description
LISP is a self-extending higher-order strongly typed dynamic strict
(but with lazy constructs) functional language.
It's one of the oldest programming language,
but also one with the nicest semantics also.
It's a good experimental platform for just any kind of computing;
it has got very good support,
including free portable development environments,
integrated structured editors, and efficient "optimizing" compilers.
Unhappily, it suffers from flaws deep enough to preclude
its use by the non-hacker :( :( :( :(.
There seem to be two standards as for LISP:
Common LISP is a huge monolithic language, with hundreds of built-in
constructs for a megabyte worth of run-time system (not talking about
add-on modules).
Scheme is a minimalistic, skimmed, version of LISP, with simplest constructs
upon which everything is built.
In LISP, everything is parsed as S-exp's (Symbolic EXPressions), which
are indeed balanced parenthesized expressions of atomic symbols. These
S-exp are trivially translated into structured data, which is interpreted
very easily. The basic constructor is the (syntactically parenthesized)
list of S-exp's, and a list is evaluated by first evaluating each element,
then applying the function denoted by its first element to the rest of the
list as arguments.
LISP is really a nice language, but S-exp's are annoying to the
non-hackers (particularly if you don't use a LISP editor like EMACS that
will help you balance your expressions). Actually, the S-exp's are LISP's
only, but deep flaw: if LISP had a freeer syntax, it would fulfill all
the requirements for (a basis to) Tunes' HLL. LISP would truely be the
one universal language but for that !
References
There are lots of books about LISP and Scheme.
About LISP, you may get the specifications for the Common LISP ANSI standard,
CLtL (Common LISP, the Language).
A great book about programming in Scheme, but that actually teaches
programming in general, is the SICP,
Structure and Interpretation of Computer Programs; just great.
GNU Emacs is a widely spread LISP-based IDE.
There are also newsgroup about LISP and Scheme,
comp.lang.lisp comp.lang.scheme, not to talk about emacs-related groups, etc.
[Note: I should ask JCh and/or HBaker for pointers about these...]
Look on prep.ai.mit.edu or any mirror site to find EMACS.
(Other machines at ?) MIT is also where you could find anything about
LISP and Scheme...
Pros
- It's a idely known and standard language, with implementation on
just any computer architecture, including very portable ones.
- We may test programs immediately, without having to wait
for our kernel to be done.
Cons
- it has got a poor type system
- it allows too many side-effects
- no standard reflectivity allows the syntax to go beyond S-exp's
- it lacks some ML-like pattern matching
- it lacks a clean macro system
- its standard (common lisp) has got too many features nobody uses.
- its module system offers no security at all.
A new HLL
Pros and Cons
Pros
- 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.
- We can correct the lacks of any existing language we would have used.
- 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).
- 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
- 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.
- 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.
- 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.
Draft
To Do on this page
Create a subdirectory for the Review alone.
Have a subfile for each language family.
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.
Instead of this bogus classification, use actual criterion:
- strongly typed or not
- type-dependent types
- value-dependent types
- dynamic/static language
- garbage collection
- single-dispatch/multidispatch polymorphism
- first/second/higher order
- prefix/infix/postfix syntax
- reflectivity
Back to the Tunes
Review Subproject,
or to the HLL Subproject.
Page Maintainer:
Faré
-- rideau@clipper.ens.fr