Reflection

[Tril]

On Mon, 4 Jan 1999, Anders Petersson wrote:
> >> >Remember, every system has reflection.  It's just how long the road is
> >> >(and how bumpy) from one system to the changed system. 
> >> 
> >> Don't forget that there's a prize for everything. Will the advantages with
> >> good reflection weight heavier than the disadvantages? (I bet you answer
> >> "yes"...)
> >
> >I don't think anyone knows.  If there was a system with "good" (fast
> >turnaround rate) reflection, we wouldn't need to have a TUNES project!
> >So the advantages/disadvantages are what we will try to find out, by
> >making a running system.
> 
> So reflection is the single reason for TUNES?

yes, basically.  Reflection is the main feature, the reason to have
reflection is to support an integrated system.  Integration will only be
useful if the components integrated are all chosen by the user.  If the
user chooses everything, then they have their own ideal OS.  Reflection is
the means by which any component at all can be replaced, no matter what
part of the system it is in.  Reflection allows you, like Brian Rice said,
to reach in to the system and choose the part you are interested in, then
everything else becomes implicit.  In other words to rearrange the entire
topology for a moment to expose that component, and arrange it back again
with the component embedded in the rest of the system.  Hmm, after a bit
of revision that paragraph could go on the page :)

> >> >> What speaks against is that mOS shows the user the true system
> topology. It
> >> >> is not as I understand Tunes does - to present the user with a view
> that is
> >> >> independent of the underlaying structures.
> >> >
> >> >There is a view that is independent of underlying structures, but the user
> >> >can cross it.  Normally there will just be a warning message that says,
> >> >"if you go here and change stuff, it won't be platform-independent
> >> >anymore."  You can still do stuff there, and it's all still objects.  I
> >> >expect lots of hackers to do this.  It will be necessary to spend time
> >> >here in order to find optimizations to make the system fast.
> >> 
> >> Blurry, blurry.
> >> Who was speaking about platform-dependence? Maybe the only thing in Tunes
> >> that's platform-independent is that user view? Well, in UniOS the true
> >> system is platform-independent, except for low-level drivers and maybe
> >> binary executables.
> >
> >I interpreted your "underlying structures" as the platform-specific
> >structures (hardware, drivers, and so on).
> 
> My fault - I wasn't specific enough. By "underlaying structures" I meant
> what the user view maps to.

like what?

> >There are two "true" toplogies.  The high level, platform indenpendent
> >part, and the low-level platform specific part.  The low-level topology
> >is the implementation of the high-level one.  Implementations are the
> >"underlying structure"... and the high-level specification is independent
> >of the implementation.  
> 
> Are all implementations low-level, and so hardware-dependant?

There is a hierarchy of specification-implementation each implementation
being 'lower-level' than its spec.  High- and low-level are relative.  The
lowest level is the specification for the hardware and its implementation
is the actual hardware.  The next higher level is any specification that
uses the hardware.  Of course for a system to work everything must be
dependent on the hardware by some path through this spec-impl hierarchy.

At *any* level in the hierarchy, the specification is independent of its
implementation. And you can exchange the implementation for a different
one by providing a different mapping from the spec to the new impl.

I don't know what this is called, maybe OO, maybe "a component model".
Anyone know a better term?

> >> >> As reflection changes the way
> >> >> the system is structured, without any help from the user, reflection
> could
> >> >> confuse for the user by changing the way *the user* sees the system. 
> >> >
> >> >Well, it could be done with the help of the user.  Anything in Tunes can
> >> >be done either with, or without, the help of the user.  Usually the user
> >> >helps first, then when s/he is comfortable with what is going on, sets it
> >> >on autopilot.  (this is true for every action in the system, not just
> >> >reflective activities.)
> >> 
> >> I'm sorry, but without more concrete ideas, the above remains to be just
> >> words for me.
> >
> >Let me try a different answer.  Of course reflection can change the way
> >the user sees the system!  That's the whole point!  People need to look at
> >information from different views, to understand it.  Changing views is
> >just another way of saying customization.  You in UniOS have the same
> >problem because you say flexibility is your #1 goal!  With all that
> >flexibility, of course the user might get confused.  But that's no reason
> >to leave out flexibility, now is it?  Tools CAN be added to manage
> >flexibility.  
> 
> I agree. Users will want to have the flexibility decreased. Novices want
> little flexibility, experienced users can handle more flexibility.
> Such a flexible design we are looking for provides too little 'flesh' to
> have a system implemented just going after the design. For example,
> standard tree structures will have to be defined, since the design does not
> enforce any special structure. Don't misunderstand me, programs must not
> rely on such implicit standards, but users will feel more comfortable if
> all computers they use look the same (like having applications in one
> defined place and user files in another defined place).
> 
> No, that aspect was not quite what was discussed, but it was what I wanted
> to say. :)

Yes, the system may be a little hard to navigate for users at first.. but
not really, since everything isn't in just one place, it is stored as if
it were in a relational database under EVERY related topic, and the main
user interface can be based on one of those intelligent db query engines. 
Get used to how to ask for stuff, and it won't be too hard anymore.
Better yet, find the way you like stuff to be displayed and set that as
the default.

David Manifold <dem@tunes.org>
This message is placed in the public domain.