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

[Marcus Petersson]

On Sat, 13 Apr 2002, Francois-Rene Rideau wrote:

> Tunes really is into building reflective computing systems,
> where software development is considered as one of the things to automate

"Automated development" sound like buzzwords to me. Can you give an 
example of some part of writing software you have or think should be
automated, and how to do that?

> You definitely should take a look at SELF.

Self, the prototype language, where subclassing and instantiation are
equivalent? Why, is Self a good environment to interface with classes
written in various langauges through a single interface? AFAIK it's a
language. I don't mind learning from the principles though. Will also
have a closer look at Slate.

However, I'm more interested in the DBC project that Kyle Lahnakoski has
presented, because it's supposed to have a multiple language interface.

This sounds a bit like what I aim for. The basic idea is to disconnect the
object implementations from any language environment, and provide wrappers
for many different types of objects and classes.

While the current object manager interface may be quite limited and
arcane, not anywhere close to your reflective ideals, I hope to improve
this with time. But perhaps it has to be limited, because you don't have
the warm and cozy environment that a single language offers.

...not to mention how limited the implementation is, but I hope to improve
this with time too. :-)

> > 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.

Well, OO CPUs are not the issue here. The wording above might have been
bad (though it wasn't I who wrote it). A better description could be:
"a library to handle objects and method calls, since CPUs only does
 subroutines". That better?


> > 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.

And still it what everyone uses. With current system there are many things
that can't be done without going through a C interface. In fact, I can't
think of any mainstream system that would exist if C (or C++) didn't.
So it has nothing to do with politics, it's more of a practical necessity.

> 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.

I might have, if this had been possible from a practical point of view.
It's not like I prefer using C rather than a "better" language, but C has
the best support. Actually, the implementation is written in C++ (which
 has decent support too), but the interface is in C. This is important,
since AFAIK most languages that can make system call of any sorts, can
call C functions as well.

> You can always go back to implementation details later
> (and then go forth toward refining you programming model),
               ^^^^^
Was that an intended pun? :-)

> 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.

Sure, it can be a problem. But the first prototypes we did in other 
languages produced very little insight and no result. It wasn't until I
started with a C implementation that the pieces started to fall in place.
It was an eye-opener. So...

> Note that I'm not saying it doesn't help knowing the gory details - it does.

This was my experience. Until at least one prcatical detail had been
implemented, very little of the abstract ideas made any sense.

> 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.

The concept is already there. Or most of it, new ideas appear as I go
along. I think the details that matter now needs to be figured out at the
level where they belong, i.e in the actual implementation language.

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

While objects require memory, they are not just memory. Memory management
is done underneath. The actual implementation will change with time, but
this particular piece of the interface should not have to.

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

Why do you say that? Parameter objects are just a way of packaging
parameters, and has nothing to do with currying, AFAIK.

> > 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.

While in a way true, not quite. We may try to narrow the gap, and build
bridges between, there remain some differences:

* PLs produce code, OSs doesn't (though perhaps they could)
* A PL's environment is usually homogeneous and strict, an OS can have
  many different interfaces to its services

Ok, perhaps a little far-fetched. ;-)  Similarities are abound, they can
both be low-level or high-level, modular or not modular, popular or good.
"Using is programming", and so on...

> 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),

Well, unfortunately I'm not. And besides, it probably wouldn't be much
idea to bother a probably already busy person I have not met with various
programming problems. :-/

Anyway, I was just throwing out a bone to see if someone was interested.
If not, it might be a good thing for me to learn more about the various
Tunes-related concepts. If some of them could be added to the object
manager design, would you be interested then?

Marcus
------------------------------------
 If you find that life spits on you
 calm down and pretend it's raining