Short note on "quotienting" (was: Comments requested)

[Joerg F. Wittenberger]

Hi Brian,

thanks for your throughout reply.  I just now came around to read it.
Yes, it did explain something.

However:

Brian T Rice <water@tunes.org> writes:

> [snipped an example]
> > > In the first case, P1, we have x as primitive, in the second y instead.
> > > With quotienting we can obtain such flexibility in choosing what is
> > > primitive and what is derived.
> >
> > Hm.  Apparently I'm wrong in the understanding of "quotienting" as
> > "quoting" above.  But here I would feel that some kind of
> > bidirectional equivalence function together with some caching would
> > do.
> 
> Yes, that's an isomorphism. The arrow framework I want to build would
> include a kind of caching system; actually it does already but is not
> sufficiently sophisticated yet for Tunes. In general there are a network
> of types and isomorphisms, so the problem is roughly analogous to routing

Isn't there a problem of "hen and egg"?  I mean there has to be a
decision what should be the first primitive paradigma (paradigma in
the sense of structuralism, i.e., an axiom which is not a syntax rule
but a singleton).

Example: For the Askemos I've choosen the existence of an inalienable
right of the user to control the actions of the object which
represents this user in the Askemos.  This is actually not an
arbitrary decision but the isomorph "math equivalent" to the basic
idea of the way enlightenment philosophers have build the foundation
of todays legal system.  (And quite the opposite idea to the mere
existence of "root" users with special permissions.)  At the end of
the day this amount to basic set theory as a basic type which I can
hardly present as derived _within_ the Askemos system; instead I need
to excape to the "real world" and immideate human understanding
(i.e. philosophy).

Do you think the Tunes will get along without such a basic type?

> > Both taken together would mean: the system needs to have a notation of
> > structures which can express functions and protocols.  It needs to be
> > able to derive tranformations rules to convert between functions or
> > protocols from the basic notation and choose the best according to the
> > context (e.g., the hardware/software it is running on) transparentely
> > to the user.
> 
> Yes, that is a decent summary. The details are a bit more hairy, of
> course.

Of course!

> They are Interfaces without the static notion of Application and
> Programmer to get in the way. If you use a capability-style concept of
> security (see http://cliki.tunes.org/Capability), then you can see that

Maybe it's interesting here how the set theoretic approach taken for
Askemos can provide a criterion to sort capability (actually AFAI can
see all rights systems) into corruptible and incorruptible in the
sense that the system will respect the inalianable user rights.

See http://www.softeyes.net/A04538159df3258ea68544531bea1c006 section
distributed authority.

> access to functionality can be given in an incremental fashion: just as
> much as is needed or perceived as generally appropriate, and not more
> without some kind of contract or at least some reasoning. One of the E
> authors gives an example where an Outlook worm has to ask the user several
> questions explicitly before it can propagate: "Can I read your address
> book?" "Can I resend to all of them?" and such. Such a model can be
> configured to keep these nasty annoyances of the current user-permissions
> system from becoming as rampant as they are.

;-) Thats how we do for the customers.  There's actually a kind of
people who really like to play games with the capabilities.  (And poor
me has to sort it out. :-/  )

best regards

/Jörg
-- 
The worst of harm may often result from the best of intentions.