Introduction and misc ideas

[Armin Rigo]

Hello Cyril,

I can't resist commenting on your ideas, because there are quite close
to what I believed when I discovered Tunes. Read me correctly, I did
*not* change my mind -- this kind of idea could be quite successful in
my opinion. I would love to see them implemented as a library for a
widely-used language, despite all we can say against these languages --
C++, maybe Java (which might really lack higher-order capabilities for
this), why not Python (I regard Perl as not OO enough).

I am talking about libraries for common languages because I am not a big
fan of Squeak-like environments. Despite all their success and
everything you can so easily express in the language and the
environment, and despite what I'm sometimes told, I find them completely
closed. I would say the same of any environment in which the most
natural way to do things (however nice it is) is with a big program
image (so that we can structure it freely instead of relying on external
files), with a big window as UI (so that we can draw anything we want
inside it instead of relying on the underlying GUI), etc. -- you see the
point. I'd also put the virtual machine in this list (our own
"processor" for freedom instead of relying on the underlying CPU).

Anyway I think something like you describe would definitely be a plus. I
also regard MS' .NET as a plus of a related but different kind; it might
be a good base for such an implementation.

All this said, I am now regarding Tunes as a way to connect algorithms
together, a kind of network between programming languages (where you
would basically have as many "languages" as you like, building new ones
from existing ones, for example like you do with monads in functional
programming -- see http://www.haskell.org/arrows/biblio.html#Hug00). In
other words, the exact opposite (or complement) of the environments as I
described them above.

I see Tunes as claiming that we don't need yet another environment but a
way to incorporate existing work. I would regard Tunes as a "viral"
program starting from a small kernel, first only able to interface with
external parts through libraries (e.g. mappings for the OS'
C-implemented system calls, as you find in many languages); then, as
needed, we describe more and more properties of these external features,
declaratively. I'll take the example of file access, seen as a service
from the underlying OS which we can use for persistent storage. We'd say
e.g. "the return value of fopen() is a handle, i.e. an integer whose
numeric value is pointless, which is meaningful to the OS exactly up to
the call of fclose()", and later add information about the external
resources this handle requires. The idea is to be declarative enough to
let higher-level functionality be implemented semi-automatically, to let
correctness be checked, and to let various lower-level implementations
of higher-level concepts be regarded as equivalent -- with the
equivalence explicit. The same applies not only to external libraries of
C functions but anything the programmer wants to regard as "outside" his
program, which can be (at the programmer's discretion) the hardware, the
various abstractions the OS uses -- starting from processes --, global
memory management, UI, etc.


A bient=F4t,

Armin.