Review of existing Languages
Preliminary Note
There are a lot of these, aren't there ?
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 broken english and typing mistakes.
Existing languages
Other language-related WWW pages
Why a New HLL
Existing languages
- Languages of the ALGOL family
- Functional Languages
- Stack-based languages
- "Object-Oriented" languages
- Logical programming languages
- Parallel/Distributed programming languages
- Languages for doing maths
- Maple
- Mathematica
(home page
here)
- Pari
- Yorick
(somewhere around
there)
- Macroprocessors
- m4
- gema
- CPP (C Preprocessor)
- awk,sed
- Languages to classify
Other language-related WWW pages
- Indices
- Yahoo's
page on languages.
- Or that from the
WWW Virtual Library
- A catalog of free
compilers and interpreters
- Here
is a WWW pages that points to several interesting pages
about programming (and human) languages.
- Some "paradigms" of programming
- Articles
- Implementational topics
- Henry Baker
(hbaker@netcom.com), a Lisp, FORTH and GC guru,
has many articles about garbage collection and other topics.
- The reference about
Linking
- Meta-tools for languages
Agora
I've been told about this most interesting Agora language.
Could anyone send feedback ?
Here's an FTP site,
and now a
WWW site.
BETA
BETA
is an OO language from those who invented SIMULA.
It is the latest advance in OO programming.
Its only current implementation is
the Mjolner BETA system,
which is commercial, but with discounts for educational institutions.
C/C++
Description
"C" is a low-level, weakly typed, static, non-modular, non-generic,
non-reflective language.
"C" was designed in the late '70s as a
portable assembler for the PDP-11 series
(remember? nominally compatible machines but with various word lengths),
and it is still the state of the art in that area, although,
as a systems programming language,
it is more adapted to the PDP-11 than to modern architectures.
In the late '80s, the small and elegant `K&R' C has become the
prey of an ANSI standards commitee; it has now become ANSI Standard C.
In the '80s, C has (in our opinion wrongly) become the language of
choice for general purpose programming. In an attempt to add the
features of general-purpose Object-Oriented languages to C, Bjorne
Stroustrup created C++, a huge, bloated, hack-ridden monster.
Writing the formal semantics of C++ is left as an exercise to the
reader.
The only positive point about it is that
it is the one standard as a programming language.
There are also other less popular "object-oriented" versions of C, such as
Objective C
or
Dynace.
References
About C, get the C Bible by Kernighan&Ritchie
(the original authors of C).
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 (GNA)'s
Introduction to Object Oriented Programming Using C++.
Look on prep.ai.mit.edu or any mirror site to find
GCC, the 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 compile test programs immediately, without having to wait
for the kernel and compiler 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++ knows only early binding
(i.e., it only compiles directly executable code),
hardly knows about dynamic library linking
(in the case of C, it's not a language 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 that 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, it's impossible;
so only front ends can be reused, which are trivial to write
(although more difficult in the case of C than with other languages).
All in all, "C" would only get in the way if used.
-
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.
-
Horrible in C and dreadful in C++ is the lack of really first-class
structured values.
This makes C nothing more than a badly specified portable assembler
(with very limited macro facility, and restrictions in calling conventions),
and gives a completely obfuscated notion of object identity to C++.
-
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 so called virtual tables.
So to make the slightiest add/change,
you must recompile the whole application.
-
Because the whole object system in C++ is based on lame
inheritance,
enhancements in a program may mean complete rewrite of
the type hierarchy.
-
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.
Note that "C" offers absolutely no particular interest when cut from all
its standard compilers and libraries, for you can no more port existing
software.
As Tunes won't support any standard "C" library
(at least as support for native code),
and requires a different compiler anyway,
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
(see OTOP subproject).
Concurrent Agregates
Concurrent Agregates is a language for distributed computing developped
by the Concert project in Illinois.
CECIL
Cecil
is an OO language at University of Washington,
participating Craig Chambers who wrote the
SELF compiler.
Clean
Concurrent Clean
is a general purpose, higher order, pure and lazy
functional programming language for the development of sequential,
parallel and distributed real world applications.
Clean is a language in the spirit of other modern lazy functional
languages like Haskell and Miranda. People familiar with these
languages will have no difficulty to program in Clean. The Clean
compiler has the nice property that it runs on small platforms (Mac,
PC, Sun), while it compiles very quickly and produces code of
state-of-the-art quality.
Common LISP
Description
LISP is a self-extending higher-order dynamically typed
strict (but with lazy data structures often implemented)
non-pure functional language.
It is the second oldest programming language,
but also one with the nicest semantics.
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.
Unfortunately, LISP syntax takes some getting used to
(it uses a very clean but unusual notation called `Cambridge Polish')
which makes it quite unpopular with many programmers.
Studying all the dialects of LISP is enough work for a lifetime.
However, there seem to be two main 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).
However, the advantages of programming in Common
Lisp cannot be overestimated:
everything a programmer usually needs is in the library,
the object system is (quite) well integrated with the
type system and the condition system (which is unique on its own).
Common Lisp is now an ANSI Standard
(we do not know how legal it is to redistribute the text of the standard
in machine-readable form, as we'd like to).
For many years, the de facto
Common Lisp standard has been `Common Lisp: the Language', by Guy
Steele. The (current) second edition is available in electronic form,
among others (in the States) from
Carnegie Mellon University.
as well as (in France) from
Supelec
Scheme is a minimalistic, "skimmed",
dialect of LISP, in which everything is built upon the simplest constructs.
Scheme has a section of its own in this review.
EuLisp (European Lisp),
is a modern object-oriented dialect of Lisp whose design was
less minimalist than that of Scheme but less constrained by
compatibility reasons than that of Common Lisp.
In particular, it has a single namespace for variables and functions
(like Scheme, and unlike Common Lisp)
and its type system is prefectly integrated with the object system.
Furthermore, the language makes use of the module system,
so that every program may import only those parts of the language
that it needs.
You may find the current EuLisp specification
comp.lang.lisp,
comp.lang.scheme,
not to talk about the many groups about emacs or ai.
LISP and Scheme repository
here
Pros
- It's a widely known and standard language, with implementation on
just any computer architecture, including very portable ones.
- Both interpreters and compilers of good quality are available,
and new ones are easy to design,
making development easy, and portability quite good.
- It is fully reflective
- It is strongly-typed, that is, type-safe for a non-trivial type system.
Cons
- the type-system is not safely extensible in a high-level way
- it doesn't allow any static typing
- it allows too many side-effects
- no standard reflectivity allows the syntax to go beyond S-exp's
- although it is fully reflective, it has no
- 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.
Conclusion
-
All in all, it could be said about Lisp's semantics
that while it offers a great expressivity
as to constructing new objects,
it is unexpressive as to express constraints on these.
About its syntax, we find that it is very all-purpose,
and adapts immediately to any use;
however, it doesn't allow to scale to specific uses where
local constraints make it too redundant.
It could be said that Lisp is a language based on syntax trees;
then, Clean, that is based on graphs, and could be
a successor (see also Prolog and Lambda-Prolog for the same in logic
programming).
COBOL
COBOL means COmmon Business-Oriented Language.
It's a very old and lame language which has got a FAQ
here.
Coq
Coq is a higher-order proof system
based on the Curry-Howard isomorphism between propositions and types,
proofs and terms in a pure functional language:
a functional term is a proof of its type's realizability.
By restraining to intuitionistic logic
(i.e. no built-in choice axiom),
it allows to extract actual programs from proofs.
The newer version of Coq does have programmable tactics (using CAML-light),
extensible grammars, etc.
The problem with Coq is that it is not reflective:
there is a one global meta-context,
and no way to meta-translate expressions:
a proof done in "Prop" will have to be done again in "Set" and in
"Type"; there are no "proof sketches" as first-class objects.
Coq has got a
WWW page,
which is no more empty.
The Coq distribution
includes full docs.
Dylan
Dylan is a new object oriented dynamic language developped
conjointly by Apple, Carnegie Mellon University and Harlequin inc.
The main design goal of Dylan was to make a dynamic language that
could be compiled as efficiently as static languages. The design
group hopes that it might bring dynamic languages to C++ programmers
(but don't worry: even some Real Language programmers find Dylan
nice).
See
Apple's page,
and
CMU's
Gwydion
project for a free implementation of Dylan.
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 values, 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.
Escher
Escher is a declarative, general-purpose programming language
which integrates the best features
of both functional and logic programming languages.
It has types and modules, higher-order and meta-programming facilities,
and declarative input/output.
Escher also has a collection of system modules,
providing numerous operations on standard data types
such as integers, lists, characters, strings, sets, and programs.
The main design aim is to combine in a practical and comprehensive way
the best ideas of existing functional and logic languages, such as Gödel,
Haskell, and \lambda-Prolog.
Indeed, Escher goes well beyond Gödel in its ability to allow function
definitions, its higher-order facilities, its improved handling of sets, and
its declarative input/output.
Escher also goes well beyond Haskell in its ability to run
partly-instantiated predicate calls, a familiar feature of logic programming
languages which provides a form of non-determinism, and its more flexible
handling of equality.
The language also has a clean semantics, its underlying logic being (an
extension of) Church's simple theory of types.
You can obtain a
report.
about it.
FORTH
The main on-line source of information about FORTH are the homepage of the
FIG (Forth Interest Group),
and this page.
Of course, the place to ask questions about FORTH is
the usenet newsgroup comp.lang.forth,
which has an
old faq
and a
new faq
The ANS document for FORTH is available in many formats from
here.
Here is an online book,
"Real-Time Forth",
FORTH, inc
is the company created by the original authors of FORTH.
Some implementations:
- PFE
is a free, portable, and super-standard implementation
of FORTH that runs on unices and PCs.
- Wil Baden's
Macro4th is a mostly standard FORTH with very interesting
(unstandard) features. Runs on unices, pcs, macs.
- F-PC is a very popular FORTH system for the PC.
The page also contains lots of useful FORTH pointers.
- Forth/2
is a free implementation for OS/2 that comes with source.
- MOPS
is an FORTH with builtin OO extensions well integrated
into the MacIntosh environment.
Gema
Gema
is a general purpose macroprocessor.
Haskell
Haskell
is a lazy (non-strict) functional programming language.
serving as a bench for much of the research in functional languages.
In particular, it has a very complex type system which unifies ad hoc
polymorphism (operator overloading) with normal polymorphism. It
might be called a functional object oriented language.
Gofer is a lightweight version of Haskell. Gofer implementations
exist that can be run on desktop computers.
There's a Haskell group at
Glasgow
head up by Simon Peyton Jones
with its own implementation
GHC
Professor
Paul Hudak
is heading up the
Yale Haskell group, and doing Haskell and music in Haskell.
See this
FTP repository.
Icon
Icon is a high-level, general-purpose programming language
with a large repertoire of features
for processing data structures and character strings.
Icon is an imperative, procedural language
with a syntax reminiscent of C and Pascal,
but with semantics at a much higher level.
The Icon project (in Arizona) has a WWW page
here.
Java
Java
is a C-like OO language whose existing compiler compiles to bytecodes.
It can be found here.
It is meant to be used as an description language for objects
passed accross the WWW.
Here is an FTP site.
Linda
Linda
is a language for parallel programming.
M4
m4 is a powerful (unlike CPP) macro-expansion program
designed as a preprocessor to more stubborn languages.
It's ugly, but it's fairly standard
(available on most platforms, including a fine GNU version).
The semantics for reflection are horrible,
so users who want to do complicated things often find themselves
compiling manually to continuation passing style.
Quick critique of m4 as a programming language
The language semantics or brain-dead, and remindful of TCL
(though simpler and cleaner):
- evaluation is based on unconstrained reflection
- you don't have closures or contexts,
- you only have pass-by-value and dynamic scoping
- quoting is syntax-based, not semantic based
- you can't escape characters in a quoted text.
As a result,
you don't have nested definitions of abstractions
but with horrible unsafe contorsions
that give results inconsistent with deeper abstraction
Building new control structures is therefore difficult
and unsafe, whereas the language proposes few basic ones.
Syntax is modifiable,
but previously defined reflective object won't be
is consistently modified.
Unless stubborn double-character quotes are used,
quote characters must be banned from output.
Also, the language support is poor as
- There are few input/output primitives,
and only output has easy-to-use syntax
- available implementations make everything but string handling
completely unefficient,
and proposes no efficient data structure but a string LIFO.
- there is no standard library
- there is no standard way to extend the language
To conclude, m4 offers reflection without abstraction.
It really should be used only as a quick and dirty preprocessor,
when little programming is needed.
I wonder why I sticked to it...
MISA
MISA is an interesting project
to design the language of next century.
ML
ML
(originally the Meta Language for a theorem prover) is a
class of (strongly) typed functional language.
ML comes in two main flavors:
SML,
with its docs
and implementations
SML/NJ,
Edimburgh ML,
Moscow ML,
and
CAML
CAML,
with its implementations
CAML-Light
and now
CAML-Special-Light,
that both have on-line docs around, too.
SML/NJ is an efficient but hyper-heavy implementation:
don't use it with less than 32MB of memory.
I don't know about Edimburgh ML.
Moscow ML is some SML implementation using the CAML-light run-time.
CAML-light is very light-weight bytecode-based implementation
that fits almost any 32 or 64 bit computer;
as a measure of its usability,
it has been used successfully for a game under X11.
The new CAML-Special-Light now compiles to native code, and is meant to
compete successfully with SML's efficiency, at much lighter cost and
resource requirements, and with a much better and cleaner module system.
SML has got a powerful but kludgy module system,
only fully implemented in SML/NJ.
CAML now has got a powerful module system too (only in CAML-Special-Light),
just much cleaner than SML's.
Here are some interesting software projects I've found using ML:
The
Fox
project from CMU to write an OS using (a hacked version of) SML/NJ
running directly over Mach.
The Coq project
of a constructive proof/program environment
written in CAML-light.
Modula-3
Modula-3
comes between Modula-2 and
Oberon in Niclaus Wirth's quest for his
ideal language...
Click
here for more information.
Napier88
Napier88
is a persistent programming system from University of St Andrews
Oberon
Oberon (now version 2)
is the latest modular OO language by Niclaus Wirth
(the author of Pascal and Modula)
(also here).
There are FTP sites for
Oberon and
the Oberon User-group.
Orca
Orca
is a language for distributed computing,
codevelopped with the
Amoeba
distributed OS.
Pascal
Pascal was a toy written by Prof. Nicklaus Wirth to teach
computer languages. Unhappily it has been taken seriously by many people.
See
Modula-2,
Modula-3, and
Oberon
for more serious languages developped by Professor Wirth.
Brian Kernighan (author of C as well as many Pascal software), once wrote
an article
"Why Pascal is Not My Favorite Language",
which is quite obsolete now that modern Pascal's (e.g. Turbo-Pascal)
are quite equivalent to C
(which also shows C sucks as much as this toy Pascal language).
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.
Prolog
Prolog
is a language for programming based on propositional logic
(not even first-order logic).
Python
Python
is an OO programming language
WWW and
FTP sites.
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. Let us try to determine
why...
Pros and Cons
Pros
- The language is reflective: code IS an object as anything on the HP,
and it is easily manipulable.
- Interaction is done through a visible stack in exactly the same way
as the thing is programmed. The interface is thus very well integrated
with the programming language, and the interface concepts are simple,
with trivial automatization. Much better than windows !
- The system is orthogonally persistent.
Cons
- The language was not extensible (well HP48's can be extended using the
assembler, but that seems kludgy).
- The language was designed with a unique execution context in
mind: single user, single-threaded, global variables.
- No support for modules and migration.
Sather
Sather
is a free Object-Oriented programming language rival of Eiffel.
Scheme
Scheme is a small dialect
(some say a skimmed version)
of the LISP language.
Scheme is among the few languages that have
a perfectly defined formal semantics,
and not a too kludgy one at that.
and Scheme programmers often find it unpleasant to program any other language.
However, Scheme suffers from minimalism,
and Common Lisp programmers often wish they had a unified library in Scheme.
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.
A selection of Scheme code can be found in the
Scheme Repository at Indiana University
The Scheme Underground
project to build a complete computing system on
top of Scheme48, a portable implementation of
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)
STk
allows access to the popular Tk toolkit for X programming via Scheme.
Pros and Cons
Pros
- Scheme is minimalistic, no unneeded constructs or bizarre rules.
- It has trivial syntax, so you can concentrate on semantics
- Its semantics are very simple, regular and expressive.
- It has the best macro system ever found in a language
- Just any program can be made a first-class object in Scheme:
it has maximal positive expressivity
- Scheme is the basis for some of the best book to learn computer science
(see SICP)
Cons
- Scheme hasn't got a large standard library.
- It has trivial syntax,
so there aren't the usual redundancy anchors
that help human readers understand programs.
- It has no standard module system
or any easy mechanism for deferred binding.
- There is no standard way to declare read-only objects.
- The read-write cons cell concept is a
low-level one that dirties the high abstraction level of the language.
- There is no standard way to restrict the extent of definition
by some requirements ofe context soundness (typing).
So while maximally positively expressive,
Scheme is as trivially negatively expressive
as such a language can be.
SELF
SELF
is a Object-Oriented programming language
based on very simple concepts which allow efficient implementations.
SELF uses trivial strong typing (much like LISP): there is no
"typecasting" backdoor to object representation, but there is no
type hierarchy.
Brown University
has an interesting course on SELF.
The Merlin project uses SELF.
TCL
TCL is a lame interpreted language, which is popular because
of Tk, a powerful toolkit to program the X-Window environment.
Those who managed to understand its semantics
try to explain it with words such as `binding-time', `runtime', `coffee-time'
and pretend it's not that bad after all.
Many better languages, including
Perl,
Scheme, and
Caml-light
have access to Tk.
And other languages have other interfaces to GUIs.
Deeper insight can be found
at the
language critique page
or in those
Comparisons of Tcl with other systems
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.
Melbourne's Mercury.
Tim Budd's Leda.
OO Info.
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 criteria:
- 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
Shall we point to the
NASM
project for a freeish assembler ???
moses
Luca Cardelli
(notably this one)
Andrew Appel
Brunel's
resources list
POET (persistent store in C++), and
Persistent STL
Back to the Tunes
Review Subproject,
or to the HLL Subproject.
Page Maintainers:
Faré
-- rideau@ens.fr
and
Juliusz Chroboczek
-- jch@ens.fr
(?)