sharing object models...

[Francois-Rene Rideau]

[Dear TUNES people, that's a reply from me to David Manifold,
 who asked me about the TUNES object model]
">" is David M.
">>" is me
">>>" is David too.


> You weren't rude,  I just never received a reply for my first letter.
   Oops. I was convinced I did reply to you. But since my mother took my
modem away and broke it, I have been getting confused about my mail,
transferring it by floppies instead of PPP (which is significantly slower,
believe me !).

> There are no hard feelings.
   Thanks !

> I am only interested to know, did you 
> receive the first letter?
   Yes I did, but I somehow, I got convinced that I already answered you,
and either I did not, or I forgot to send it, or it was lost during my
sendmail-by-floppies. Please excuse me for the inconvenience...



> I told you that I was making an operating system of my own.
> I said something to the effect of "I can not comprehend an
> object system without encapsulation" Do you remember this?
   Yes I do remember; but I wanted to say that the TUNES model *did*
offer encapsulation through the concept of *contexts* (aka meta-objects).

> Either way, I 
> only want to know whether you read it or not as reference in basing my 
> further conversations with you.
   Yes, I did. Sorry again. I have the message saved in my archives...



>>   Note that it is also one of the reasons why I've set up the WWW pages.
>>I know these pages are not always very good, and that one may get lost at
>>reading them. But I can't make them better without at least some
>>feedback about how I could make them better. So if you read them, and
>>then ask me to explain you some part you didn't understand, I will be glad
>>to explain you, and to correct the pages; but I'm sorry to say I'm tired
>>of explaining everything from scratch everytime as I've much too much work
>>to do for now (about Tunes as well as about my studies).
> 
> The WWW pages are fine.  I will aid you in filling in my understanding of 
> the conceptual Tunes system by reading the pages and your mail very 
> carefully before I ask questions.
   Thanks ! *That*'s how I can improve the WWW pages (besides writing
down all my pending ideas).


> But just to let you know my position,
> your writing (either in Web pages or letters) has been a little above my 
> head.
   Yeah, I've been told that already. Ideally, I would make some
multi-level document, where you could have explanations more or less
technical, assuming more or less background from the reader, etc. But
that's a mess to do with HTML. HTML is hyper(1)-text. I want hyper(n)-text
for all ordinals n (hey, Chris, you could put that in the Interfaces
stuff, couldn't you ?).


> I realize our differing backgrounds makes the documents seem 
> obscure to me.
   I'm overwhelmed with work, mail, etc, not to talk about all the
administratrivia related to my being student at the ENS for which I'm late
late late. How I wish we could meet, so work would go so much faster !!!
However, not two of us live in the same town, it seems, not to talk about
people being on different continents...


> I, like a recent poster to the mailing list, also see the 
> need for a strong data model (if that's what you call it).
   Ahem I'll reread all these mail, because I don't grasp what you mean by
"strong"...


> My object 
> system that I have refined in my mind for my operating system, has an 
> object data model based on readings I have done in Turbo C++ and 
> Smalltalk introductions, and the docs for a game called ZZT.
   I dunno about ZZT, but the previous are very old technology, with
many misleading ideas. I too was impressed when I came to learn them,
but there are so many flaws in either.


> I realize 
> this is not a strong background in a variety of OO paradigms.
   Well, we all have to begin someday. My background was not so good some
years ago...

> I do not know LISP.
   I guess anyone should know it well to be serious about computing.

> The reason I do not like C++ and Smalltalk very well is they 
> do not have a strong coherent (in my mind) object model.
   Their models are experimental, and devoid from any theoretical
reflection.

> Or maybe it is 
> just that my object model makes more sense to me.  I do not even know 
> what my object model is like!!
   Perhaps by trying to explain us, it will appear clearer to you.
That was the case for most ideas I redacted on the WWW page: by writing
them down for other people, I had to understand them better.


> Perhaps you would need to know more about 
> MY conceptual object model before being fully able to help me understand 
> the Tunes object model.  I basically made up my object model in my head 
> from what I thought was logical, coherent, and VERY USABLE-- usable 
> because of the following reason:  My OO Environment/Operating System was 
> simply to be a tool for me, to represent concepts as objects in my 
> computer.  Previous to discovering OO concepts, I had many many ideas on 
> programs I would like to make, and ideas on ways to make my computer much 
> more useful and efficient for ME to use.  Since making my computer easier 
> for me to use included a VERY HIGH LEVEL of customizability, I was sure 
> that it would be possible for other users to make my environments easy 
> for themselves to use.  So, please tell me what you think, if it would be 
> helpful to you if I related my object model the way I see it.
   You seem on the right path, though a ten line description for an object
model is always vague.


>>> However, I am still really very interested in Tunes!
>>   I'm glad to read that !
> 
> Tunes is very different from my operating system.
   How ? Are the differences opposing your ideas, or completing them ?

> My OS is designed from 
> a perspective of "how many of my ideas can be implemented with OO? Well,
> all of them, if I make a good enough OO system, because I don't see any 
> system currently that meets my needs."
   Well, I don't like the term "OO" because it's much too vague, and
associated to a lot of crap (C++, and many commercial "OO" software,
"inheritance", etc).


> I admit I didn't do much 
> searching for a system that meets my needs.
   If there had been one, it would have meant your ideas are not
very advanced ;->

> I read a few things and 
> thought about them a lot until I could come up with a system myself.  
> Actually, I thought designing my own system would be EASIER than trying 
> to find another system and learn it, because I thought I was capable and 
> my OS would be best suited to ME...
   That I don't think is a valid argument: the problems people have with
computer are seldom so specific that nobody else have them, and problems
are eventually quicklier solved by many people than by one alone. Which is
why people share their effort, and why they use "OSes" (see the definition
in my article "Why a New OS").


>>> I would especially like to help
>>> work on conceptual-design of your High level Language.
>>   I'm especially looking forward to any collaboration on this subject.
> 
> I am ready to attempt to design a complete HL Language in my mind that 
> meets your specs.  Only I have to understand your specs.
   Hehe.


> In Requirements.html, you write about Purity.  I do not think Purity 
> applies very well to my OS design because of the way messaging works-  If 
> an object wants to accomplish a task, it sends a message to another 
> object.
   That's low-level implementation detail to me. One principle of
TUNES' high-level-ness is that nothing gets specified below its proper
abstraction level, and thus can get migrated from implementations to
implementations, so as to maximize efficiency.


> Each object can only perform tasks relevant to itself, meaning, 
> no side effects.  What actually happens is objects only have access to 
> data that is contained within them!  Outside data MUST be accessed by 
> sending messages to other objects.  Since this is the way I think, purity 
> does not apply to my object model.
   Purity is a most important feature in TUNES. Things we know are pure can
be implemented much more easily that things we don't know are pure (likewise,
there should be a way to say when functions are linear in a variable, etc).
Also, part of TUNES' security relies on logical specificability of programs,
and correctness proofs. Purity makes all that *far* easier.


>   You also write about Scalability.  I see my system as being built from 
> simple objects, that combine or are used by more complex objects.  The 
> only way scalability could be made UNAVAILABLE is if some simple objects 
> that were used in some more complex objects were not made accessible for 
> the every day user, but only for the programmer. (example: someone writes 
> a function, that is private but called from their other function, that is 
> made accessible to everyone.  If the private function performed a more 
> simple task than the public one, and the user wanted to scale down the 
> computer's power and call the more simple object, the user could not do 
> this only if the function writer made the function private.  But, since 
> in my OS, I planned on making all parts of my modules public and 
> available for anyone, scalability would not be a problem. Of course, 
> "it is not possible to make a good programming language in which it is 
> impossible to make bad programs", likewise, I doubt my OS would be any 
> good if I PREVENTED people from being able to make private functions.  
> There must be a use for them, the use is just not in providing scalability.
   Ditto.


> The rest of Requirements.html seems easy for me to understand and grasp.
   I'm glad it is so.


>>> The reason I was so
>>> upset in the first letter was because I didn't understand your object 
>>> model.
>>    Yes, I know I must expand on that. I'm currently working on a document
>> (yet another). The background in which I'm throwing out those ideas is some
>> logic and type theory. Here are some ideas:
>> * The basic concept is a "theory", made of "constructors" and "destructors".
>> * Constructors are a list of valid rules to build new objects, much like
>> defining an type in any strongly typed lambda calculus. Actually, such types
>> are particular cases of "theories". Note: what computists call 
>> "constructors", algrebrists call "generators".
>> * Destructors are functions that are external to the theory, that allow to
>> talk about objects, to consume their information, to map them to external
>> objects. Somehow, they generate the "dual" of the structure, functions that
>> take arguments in the structure.
>> * Having theory packages as *both* constructors and destructors is what
>> distinguishes us from usual systems, 
>> and allows us to have quotient structures:
>> existing systems automatically provide destructors for freely generated
>> structures, but manipulating other structures always results in explicitly
>> using (i.e. low-level implementation) preimages in free structures.
>> * Destructors imply the existence of a meta-theory, and hierarchies of
>> metatheories. Tunes will be reflective in that sense (you can really
>> abstract over *any* theory).
>> * Much like what happens in original model-theoretic logic, a "type" is
>> a theory enhanced with some additional symbol representing a constant
>> object.
>> * Each theory is a constant object, that you don't modify but explore and
>> refine. But by refining the meta-theory, you obtain "variable" objects.
>> That is, there is no really "variable" and "constant" objects; all are 
>> locally
>> constants. Because some vary faster (and the range of change speed is very
>> wide, from 1 nanosecond to centuries, or ages of the universe), you may
>> implement them so that some changes are done efficiently than other.
>
> Yikes!  This is really foreign to me.
   This was a short draft. I hope I can make it clearer in a longer version
that does not require the same background in Logic.


> My object model basically summed up:
> 
> Everything is an object.
   That I call "Uniformity". The word "object" is foreign to that. Fuctional
languages are uniform, too. Actually, having meta-objects as objects too is
called reflectivity...


> Objects are either classes or instances (but 
> can be both).  A class is defined as an object that:
> 1. Stores the information necessary to create an instance,
> 2. Has the capability (function) to create an instance, and
   Ahem. 1. and 2. I would call "second-order functions". Because classes
are objects, too, you obtain higher-order functions (which does not
always mean reflectivity -- see Coq ):

> 3. Provides identity to objects:  Each object has exactly one class,
>    and each class is unique.
   This is called "unicity of context". Though unicity is helpful for the
consistency of low-level encoding, at high-level, unicity quite constrains
the programmer. One thing that people do everytime is to identify isomorphic
objects, etc. This is just incompatible with unicity. It is kind of the
same constraints as linear programming pose on programs: it's very useful
for the implementation, and compiler output should respect it when possible,
but costs too much for real high-level programming.


> The information stored in a class (point 1. above) required to create an 
> instance is the following:
> a. Objects that will make up the state of this instance.
>    Here, these objects are referred to by class, and when an instance
>    of the class containing this information is created,
>    the instance creation mechanism recursively also creates instances
>    of the objects that make up this object's state, and stores
>    references for them.
   This I call basic constructors, that is, functions that return an
object in the class.

> b. Methods that this object can perform.  A method is local to an object,
>    each object has its own methods.  Each method in an object has a
>    unique name.  Methods in different objects, even with the same
>    name, are different from this method.
   This I call basic destructors, that is, objects that consume an
object in the class (which would take its full meaning in linear logic).


> Classes do not have to be created from nothing.
   Personally, I don't imagine what "being created from nothing" means.
You always need something in the context.


> Classes can be created 
> by specializing on other classes using inheritance.
> The classes that a 
> class specializes on are part of the definition of the class that is 
> specializing.  The definition of a class can specialize on more than one 
> class.  (Multiple inheritance)
   Inheritance (what is called inheritance in "standard" "OO" languages,
single or multiple) is just a very limited way to refine classes
(see the Glossary entry:
"http://www.eleves.ens.fr:8080/home/rideau/Tunes/Glossary.html#inheritance").


> Anything that can be done, is done by sending a message to an object.
> A message consists of a destination object, and the name of a method in
> the destination object to be invoked.
   This is called the "message passing model", which identifies
objects and contexts (thus yielding unicity of context above),
introduces lots of unneeded impurity, and introduces single-dispatch
(or dispatch on only one argument). Also, if full objects can be given
as arguments to methods, it is a very dirty low-level way of implementing
second-order functions, while in the opposite case, it means first-order
functions only.


> My message is becoming long.
   So is my reply :( :( :(

> I will further explain my ideas at your request at a later time.
   Yes, please explain your point of view as you read the TUNES way,
so we can compare and deepen each other's ideas.

> Please do not take my comments to be opinions 
> of the way Tunes should be.
   Don't worry about that. However, even though you may make choices
opposite to Tunes, I'd like you to be aware of the critics we have against
such choices, so you know what you're doing.

> So far, my project and Tunes are completely separate.
   Jecel, who also has his separate project Merlin, is a very active member
on the channel, and we appreciate his wisdom. I'd be glad you stay with us
and share your ideas too, even if you don't merge your project with Tunes.

> I have related my object model to let you have some indication 
> of where I am coming from, so that you may more easily help me understand 
> Tunes.  Please ask for clarification of my explanation of my object 
> model.
   Well, what you do looks very much like smalltalk. How does your model
differ from it ?

> I am sure I did not explain nearly all of it.  When you 
> understand my object model sufficiently, perhaps you can explain Tunes in 
> a way that I will more easily understand.  I know ideas may mix.  You may 
> have some ideas on how I may improve my understanding of MY object 
> system, and you may gain ideas from my system that will help you with yours..
   Yeah, understanding other people helps understand oneself, and vice-versa,
because people are so much similar, and they are part of a same world.


> Perhaps the last you will get out of my explanation is some of the 
> vocabulary with which I am familiar with in regards to objects.  Your 
> explanation did seem to confuse me because of how you were using some of 
> the words that I was used to using differently. (for example, "object", 
> which I think of as a conceptual unit.  or "function", which I think of 
> as a procedural unit-- as in the OLD programming style, like C.
   "OLD" is not the word. Functional programming is somehow older even.
The word is "first order procedural".

> In my new 
> system, "functions" are relaced with methods.
   Functions are more generic than methods. See what's being said by Patrick
about methods being a clumsy way to dispatch functions.

> "theory"-- what does your 
> meaning have to do with a scientific theory. I do not know "theory" as 
> anything other than a proposed method of scientific thought, for example 
> in the phrase "Theory of Relativity."
   I was using the term as in formal model-theoretic logic (see any book
about modern classical logic).

> "constructors"-- I know these are 
> functions in C++ that are called when an object of a class is created.  
> and "destructors" are functions called when an object is destroyed 
> (removed from memory).
   I used the terms differently. See above.

> "Type" in C is what each variable has, and how 
> arguments to functions are checked.  In my OS, "type" is solely 
> determined by the class that an object is.
   I see no clear difference between the two (apart the C type system
being much less expressive).

> Are any of your uses of these words similar to the definitions I have
> for them?  If not, what *ARE* the ideas you are trying to get across
> similar to?
   See above, and in the Glossary, and in the HLL/Requirements.html,
Review/Features.html pages. Sure I should explain it better in the
HLL/Semantics.html page. Help appreciated.


> You seem to be capable of coordinating a project over the Internet.
   I wish I was as sure of it as you are...

> I am 
> good at programming, and conceptualizing things at a very abstract 
> level.
   Good.

> I have never tried to communicate the ideas for my OS before, 
> whereas you have been posting WWW pages about yours for some time.  I 
> have not communicated my ideas, because I have not found anyone capable 
> of understanding them (my friends are all just learning how to program, 
> even though they have worked with computers for years.  I have always 
> been interested in programming computers.  Since my friends could not 
> understand the concepts I have, and I do not get out much except with my 
> friends, the Internet is a fine place to find someone to tell them to.
   Communicating helps *cristallize* thought. Until such cristallization
is done (which means you're able to express your though, even if you
don't), your thoughts are confuse, and you only believe you have an idea,
which in fact is only a vague feeling. I'm talking about everyday
experience here...

--    ,        	                                ,           _ 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://www.eleves.ens.fr:8080/home/rideau/Tunes/"