Class -> Object -> Thread

[Gary D. Duzan]

   How's this sound for a small idea? A chunk of code is a class,
with no external interface except an initialization entry point.
When an external entity initializes the class, it acquires passive
state and sets up its interface, but is not (necessarily) active
afterwards. When a method call is made, either internal or external
to the object, the active method becomes a thread, including active
state (registers, stack, etc).
   Note that this has no mention of how the class code is generated,
how method calls are implemented, or concurrency semantics. Can we at
least agree on something like this as a base concept to work from?
We are never going to agree on anything if we start from 40K of
description, mostly because I keep falling asleep/getting lost while
trying to digest it all. Let's build a small core of agreement; a
microdesign, if you will; and build up from there.

   On another point, I see no reason to make tiny to small objects
addressable throughout the system. I believe that there have to be
atoms in a language/system. What would be the good of defining a
system-level interface for every integer variable in every program?
Just because I am special and can access another object's state
doesn't mean that I am accessing objects within it, the reason being
that I am not following the interface rules set by the object.
   As for a special language, a LLL, and security for MMU-less
machines, I don't believe we need them. Defining the system entirely
within a new language would hamper the use of other languages in the
system. The coordination language concept I referred to earlier has
nothing to do with general purpose programming languages. Rather it
is a conceptual base for adding a standard communication mechanism to
an existing language. Maintaining consistent syntax across langauges
would be a goal to aim for, though not, I imagine, always
possible/practical. As in most cases, consistent semantics are more
important than the syntax. I see no reason to use a LLL when we have
all this wonderful compiler technology lying about. And I would say
that securing MMU-less hardware would be more trouble than it would
be worth. MMU-less machines are going to be single-user anyhow, for
the most part, so there shouldn't be as much to lose. By the time
we get this thing finished, you will be able to get an MMU out of
a vending machine for 50 cents, anyway. :-)

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts