Tunes

[Richard Stallman]

       While GNU focused on Unix compatibility, so as to allow a seamless
    transition from a corporate racket into a free software market,
    Tunes focuses on providing cleaner abstractions
    to free software developers, so as to reduce the overhead of

I would say that that is the purpose of the HURD, also:
to provide a clean set of features, not *only* Unix compatibility.

However, the method chosen for the HURD is very different from
what you are talking about.

You seem to envision that all programs that run on TUNES will be
written in your new functional language.  I think that is not a
realistic idea: you might be able to write that system, but no one
would use it.  No one will rewrite all his existing programs into a
new functional language just to use TUNES.  I certainly would not be
interested in rewriting GNU Emacs into that language.  I'd rather
stick with a kernel and library that can runs C programs, so I can use
GNU Emacs as already written.

Likewise, Unix compatibility (including POSIX support) will remain
absolutely essential; a system which lacks this compatibility will not
be useful.  It is true that you can provide that compatibility in a
higher layer above a simpler cleaner interface.  That is, essentially,
what the HURD does.

You seem to have in mind developing both a language and a new
operating system.  I think you are planning too many large projects.a
If you try to do too many jobs, you are less likely to succeed in any
of them.

So I suggest that you start by implementing a functional language
compiler that can work on existing Unix-like systems.
Given your ambitious goals for the language, that by itself
could take a few years.  My understanding is that functional languages
generally don't give good performance; figuring out how to get good
performance from a functional language could take a long time.

If and when you're finished with that, then you could start
designing a new kernel, if you still want to.

To get good code quality and support many CPU types, I suggest
implementing the functional language with a front end for GCC (just as
Ada, C++ and Fortran are implemented).  This means you would generate
GCC's "tree" data structure--see the files tree.h and tree.def.  Look
at the C front end, which is comparatively simple, to see how a front
end interfaces to the rest of the compiler.

I suggest implementing an existing functional language, if one exists
that is suitable for what you have in mind, so that your compiler
might appeal to the people who already like that language.

       Dynamic partial evaluation and invalidation will be used to
    provide excellent performance in a dynamic system,
    and will encompass code generation, caching, etc.

Automatic inlining may not be a good idea.  It is inconvenient for
debugging.  If the function foo has been inlined in many places then
you cannot type "break foo" in the debugger and catch all calls to foo.