Would Tunes be interested in this Object manager...?

[Francois-Rene Rideau]

> I have had some trouble figuring out what the point of Tunes really is. It
> is somewhat unclear whether you are into object systems or if your main
> interest is in creating new languages.
Tunes really is into building reflective computing systems,
where software development is considered as one of the things to automate
(partially, in as much as possible, ever more).

> an "object manager" I have written on behalf of
> KOSH (http://www.kommunity-systems.com).

> It's a bit hard for me to describe its purpose. One definition is that
> it's "the minimal piece of code needed to handle objects"
You definitely should take a look at SELF.

> or "an extension to the CPU to let it deal with objects".
You might be interested in the failure of the i432 and other "OO" CPUs.
I remembered fancying a OO CPU, back in the time I had been brainwashed
by the C++ (1991), wondering about how to emulate that with i386 segment
descriptors, and sadly realizing how awkward and slow that would be.
Now I know better: there is no need to do at runtime what can be better
done at compile-time. That said, Lisp Machines have shown that parallel
type-checking can be useful. Maybe once again, that tells about what are
the better and worse traditions to get inspiration from in computing.

> Here are the most important functions of the object manager:
> 
> * Find(char* name)
The very idea of specifying things in C is bad.
C might be an acceptable implementation language
(on political grounds more than on technical grounds),
but it is a very bad language to define and declare semantics.
I propose that you try specifying your programming model
in Haskell, Scheme, OCAML, CL, Mercury or Oz.
This will give you a clean and powerful first prototype,
while freeing you from implementation hurdles.

You can always go back to implementation details later
(and then go forth toward refining you programming model),
but it is very important that your core programming model
be pure and simple enough to be understood by humans and computers;
starting from the extension of a low-level programming language
will only lose you in gory details that won't lead you anywhere,
because you won't know where to go -- you'll only get more and more
conscious of that sticky tar that you're trying to get out of.
Been there, done that, back around 1993.

Note that I'm not saying it doesn't help knowing the gory details - it does.
But you better learn the details of WHAT - i.e. start from the big picture,
so you can know which details matter and which don't.

> * Release(handle h)
You should also learn about automatic memory management.
	memorymanagement.org

> * MakeArgs(int argc, void** argv, char** namev)
Ouch. All the disadvantages of currying, with none of the advantages.

> However, you should probably keep in mind that this is not designed to be
> a programming language in the usual sense, but the foundation for an
> operating system.
The whole distinction between programming language and operating system
is unfounded.

PS: since you are in Chalmers, I suggest you study with Lennart Augustsson.
He might not share the Tunes philosophy (might not even know about it),
but he is a truly great hacker, who can open new horizons to your (and our)
understanding of computing. If you see him, say a respectful hello
from us Tunespeople!

Yours freely,

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
[  TUNES project for a Free Reflective Computing System  | http://tunes.org  ]
Nine women pregnant for one month does not have the same end result
as one woman pregnant for nine months.
	-- Werner Von Braun, when asked by the US government
	why tossing scientist at the 'space race' was not helping.