HLL/INT: What is an object, anyway?

[Francois-Rene Rideau]

> "'Chris Harris' B. Harris" <chharris@u.washington.edu> wrote:
>> In the past, we've had two very distinct versions of an "object".
>> First was
>> Mike's old cells proposal, which provided a pretty solid framework for
>> low-level objects (or cells, if you prefer), but seemed pretty far from what
>> we eventually wanted with the HLL, etc..  Not that he meant it to be used in
>> the HLL, of course.  Just that we never got around to briding the two....


> There were several separate ideas: cells, toolboxes, etc...
> 
> I see no reason why they couldn't be refined into something that was
> integrated with the HLL. But we didn't seem to be moving in that direction.
   Yes I think all these are really LLL concepts. Surely useful LLL
concepts, but surely not HLL concepts: why force the programmer mind
about stacks and suches ? No HLL does.
   Now, the LLL is integrated into the HLL, so somehow, yes, whatever
results from these concepts will be integrated into it, too. Just from
the high-level point of view, these won't be basic.
   I admit I haven't thought much about these, though. I've
rather wondered about high-level ideas, even more low-level details.
I think we should really distinguish (1) the way things are implemented
at assembly level, which should be very ad-hoc and implementation-dependent,
(2) the way objects (including low-level ones) are encoded and conveyed over
a network during migration, and (3) the high-level semantics of user-visible
objects.
   (1) is for LLL subproject, (2) for Migration subproject, and (3) for HLL.
Sure the three are deeply interrelated, and the subprojects will have to
interact a lot before to find a workable solution; but the three have
truely different goals and constraints (I think), and induce different
point of views on the designer and implementers. Trying to impose one
point of view to all the other projects is an error, I think, whether it
be the LLL, Migration, or HLL point of view. Everytime one discovers a new
point of view, one tends to think it's the only valid one. While this is
quite a human mistake (than even I sometimes fall into -- please tell me
when I do and do not realize that I do !), this also leads to dreadful
results.


>> Second is the definition of "object" found in the TUNES glossary:
>> "A unified concept to manipulate computer abstractions".
>> In other sections, it goes into more depth about how unified
>> implies that this concept should be simple,
>> universal, and how much of TUNES' power will come from this.
> 
> Right.
> 
>> Now this second definition is cool; it sounds a lot like what TUNES is
>> looking for.
   Thanks a lot ;-) ! Actually, apart your Interface pages and Rainer's
feedback, everything in the WWW is mine :( :( :(


>> But it still doesn't answer my question of what an object is.
>> As nice as theory is, it remains true that we must eventually come down to
>> something that can be expressed, through various abstraction levels, into
>> native machine code (or perhaps C in the case of the OTOP project).  So what
>> can we can an object?  Seems we can't have much of an "object oriented" OS
>> without answering this question.
>
> Yes - there must be a link between the philosophical definition of an
> object and the implementation oriented one.

   So my definition for an object would be:
"anything whose semantics can be finitely coded into a Turing Machine".



> I'll paraphrase Mario Tokoro's ( philosophical ) definition of objects:
> 
>    1 - it has a unique ID
   That's quite the idea (hehe). Now what is a unique ID ? In what space
does it live ? This becomes a circular definition. Identifying for
the sake of identifying is no use. Of course objects can be differentiated
from each other, but this should be done according to useful semantical
differences. Which is why I rejected this point. Just saying "we consider
objects" is enough and encompasses it.
   [Hey ! I'm adding this comment to the "object" Glossary entry...]


>    2 - it devides the system into the outside and the inside parts: it
>        has a well defined *interface* between these parts



> To get a concurrent object, he adds:
> 
>    3 - it has computing power
   Yes, but *what* is "computing power" ? Won't an integer be an object ???
Again, if this means anything, it is encompassed by the fact we are talking
about software objects.

> The second part of the definition implies that an object has a private
> memory.
>[...]
> When we try to come up with an implementation oriented definition, we
> see that 2 has something missing.
>[...]
> It is hard to define the inside of
> the object in a complete way.
>[...]
   Yeah, and I think the fact that there is a memory of a state that changes
would be a far better characterization. But this seems to flow from the fact
we are using finite computers in a dynamical world. So why not just say
that ? This is much more simple than this point 2 that only postpones
all the problems.

>   I have decided to make this explicit in Merlin
> by say that "an object divides the system into an outside, an inside
> and a deeper inside". There are now *two* interfaces. The new one,
> between the object inside and the deep inside, I call the "reflective
> interface".
   This is I think a distinct problem. I interpret it by the fact
that objects are defined inside some space; their semantics are expressed
in terms of other objects, etc. That is, every object's semantics are
definable as a meta-object. Circularity is avoided by having the computer
(or "real-life") as a founding axiom.



>> Of particular interest to me at the moment is how "OO" (in the modern
>> computing world definition) low-level (or high-level -- is there a
>> difference?) TUNES objects will be.
   I'm not sure this has meaning of considering objects individually to be
OO. Providing a unified point of view is a global, not local, property of
the system.


>> Having no kernel, it would seem
>> difficult to support inheritance and other rather complex OO features
>> without help from the objects themselves.
   I don't consider inheritance as anything else than a low-level hack.
Delegation (importing and exporting objects), or for the functional people,
functors (aka higher-order functions), are a much more generic way of doing
things.


>> This is cool, but what if we
>> wanted to have standard, system-wide inheritance or something?
   Again, inheritance is a hack that has local semantical change involve
global inheritance tree manipulation, which is lamest. Delegation/Functors/
higher-order functions needs no such thing. Now, people are free to use
inheritance-based "OO" programming, and if they do, standards will
emerge; but I don't think we should support inheritance ourselves
(well, of course, we should provide syntactic sugar for functors so they
need no more hassle than inheritance requires in the particular cases
when we need no more than inheritance).
   It appears to me that inheritance is like requiring that functors be
applied only once, and just after they are defined, plus requiring them
not to use twice an argument or even to have two times the same argument.


>> Is this
>> something TUNES will be able to do?  Can we design intelligent
>> UI/database/math/whatever libraries without this, or some other good
>> organizational scheme?
   We won't have lame inheritance, but sure we'll have quite a better
organizational scheme: Higher-order functions (a cleaner version of the
SML functors), plus all the syntactic sugar a reflective language can provide.


>> Any thoughts to share?  I'd like to get with my "job" and
>> start helping with the UI and/or HLL syntax.
>> But I'm hard pressed to know where to begin either
>> of those until the HLL semantics are fleshed out a good deal more....
   Well, if you don't think you can help produce a new HLL already, I
invite you read about existing languages and systems: SML is a good
start (see the Fox system written in SML), as well as Haskell, SELF,
BETA. The Review Subproject has tons of pointers to other languages
and systems, and you could also add a review of existing user-interface
packages...
   I'll tell more after my exams...


> It is a very hard job! You are right that knowing "why" we are doing
> things is the first step before worrying "how" we will be doing them.
   Pardon my self-contentment, but I think I already have a clear idea of
the "why" and many ideas about the "how". Though these ideas are sure not
perfect, I have spent a long time developping and refining them (there
was a time when I gazed with wonder at C++). I'm so sorry I can't
explain them better. Please tell me what is wrong or missing about what
I already put in the WWW pages. Sure if we could physically meet,
communication would be easier...
   Anyway, I deeply recommend to anyone to study functional programming
at least a bit. Though the state of current FP languages is far from
perfect, it opened my eyes to a world of which I had little to no idea.
If you could study a bit of abstract type theory (particularly the
Curry-Howard isomorphism and higher-order logic), it'd be even greater.


> In fact, I wrote an article called "Why objects?" in 1983 where I gave
> three reasons why OOP was important ( I'll make a translation available
> in my next release of my www pages ). Another important reason was given
> by Alan Kay:
> 
>   All complex systems are built from a collection of smalled componentes.
> Why divide a computer system into weaker things like procedures and
> data structures? Why not divide the computer into hundreds of small,
> specialized computers - make each part as powerful as the whole!
   This sounds unclear to me. Again pardon my self-satisfaction, but I'd say
that Alan Kay himself has not understood everything. He sure is a fine
artist and technician, but he doesn't look like a fine theorist.
   I interpret that as an unconscious call for reflectivity: all objects
are to be considered together with their semantics, a meta-object that
potentially covers all the system together.


   To conclude, I'd like to say that really, I see nothing more in the OO
fad than Unity in the way we consider computing. I myself would add
Reflectivity, but if we are to call C++ or other such crap "OO", this seems
not to be a requirement.
   So I'll point again to the TUNES Review and HLL pages...

   Well, I was meant to study and not do any tunesing until my exams are
finished. Aaaarrrggghhh !

--    ,        	                                ,           _ v    ~  ^  --
-- Fare -- rideau@clipper.ens.fr -- Francois-Rene Rideau -- +)ang-Vu Ban --
--                                      '                   / .          --
Join the TUNES project for a computing system based on computing freedom !
		   TUNES is a Useful, Not Expedient System
WWW page at URL: "http://acacia.ens.fr:8080/home/rideau/Tunes/"