Reflection and quotation

[Kyle Lahnakoski]

"RE01 Rice Brian T. EM2" wrote:

> > -----Original Message-----
> > From: Kyle Lahnakoski [mailto:kyle@arcavia.com]
> > Sent: Friday, August 18, 2000 6:01 AM
> > To: RE01 Rice Brian T. EM2
> > Cc: 'tunes@tunes.org'
> > Subject: Re: Reflection and quotation
> >
> > A distinction between state and the ability to access the
> > state must be made.  I do agree that accessing the state can/
> > must be done though functions when considering meta-programming.
> > But I do not care how the state is realized, it can be primitive.
> 
> That's an interesting way to look at it, and we obviously agree beyond the
> level of terminology. However, I think I need to add one minor point to
> this: when I speak of state or attributes as based on functions, I also mean
> that I don't distinguish between "accessing state" and what a function does.
> This is roughly similar to what Self and Smalltalk allow (and much more
> similar to Lisp object systems) in that accessors are syntactically
> indistinguishable from other functions on the object in question. One of the
> ideas (hidden albeit) in the idea of the Tunes orthogonally-persistent store
> is that state is just caching (memoization, if you will) of function values.

That is interesting.  But it appears that the state of a single variable
is being pushed into a larger world state that is doing the caching.



> If you're thinking of your objects as denoting some "non-mathematical" idea
> (one not usually associated with functional ideas like Jecel's pegboard idea
> in Self in the other current e-mail thread), then the functions are just
> "user-choices" which *must* be memoized because (or if?) they can't be
> reproduced algorithmically. This relates to my idea of Arrow where the
> important part of a computing system is that it conserves information until
> discarded (coupled with Chaitin's idea of algorithmic information theory, of
> course).

We agree here.



> > It depends on what you mean by exist.  If you mean exist in terms of
> > being explicitly referenced in a machine, then I would agree.  On the
> > other hand I like my functions to always exist in a giant function
> > space.  f, g, f*g, fog anf f+g always exist, it is only a matter of
> > whether the machine is referring to those functions at any given
> > moment.
> 
> I'd like to mean both, of course (since both are needed by computer
> languages). In one case, I want my contexts to denote objects that
> specifically define what that object can do. In other cases, I'd like the
> object to act as a container for all objects of a specific type or
> specification. In the latter case, a hook from the lookup function in the
> meta-object allows those objects to be generated and cached on-demand.

It appears you are mentioning the classic difference between implicit
and explicit sets, or in other words, classes and formal sets.  Maybe
you have more insight into this matter than I do.  If so may you
elaborate?



> So, given all of the above discussion, what are your thoughts on quotation?

I thought I was giving that.  For every quote there is a context in
which to translate the quote into an abstract reference.  Applying this
to a textual language makes us conclude that the abstract reference must
be represented.  There are two solutions to representing abstract
references textually:  The first is to quote some source code, be sure
to remember that allowing quotes in quotes forces the alphabet of the
language to be infinite.  Or, the second, provide a function the assigns
source code to a variable name.  You can see that the new variable names
are essentially increasing the alphabet of the language.  Quoting is
simple.

It is the referencing that is difficult to model.  There will have to be
defined the CLASS of all references the machine currently makes.  This
is a class because having explicit objects, available for reflection,
will force the system to have an infinite number of them.  There would
also be the SET of explicit references.  This set is finite because the
system will only be interesting in a finite number of objects at any one
time.  The bridge between the infinite class of references and the
finite set of references is low level reflective function.  This
function must be aware of the hardware architecture (or VM architecture)
and the method that references are stored.   


> > > > The more general concept of referencing is what I define next.
> > > > Referencing is the use of unique attributes to identify an object
> > > > uniquely.  For example I can refer to myself using "The Kyle
> > > > Lahanakoski
> > > > that lives in Canada".
> > >
> > > But what if there are two (or many) Kyle Lahanakoski's that
> > live in Canada?
> > > It's relative to context, of course, which is why
> > reflection (and therefore
> > > using (higher-order where necessary) functions instead of
> > references per se)
> > > is what's called for. I'm assuming here that context can
> > change without the
> > > computing environment's "permission", which it always does,
> > even though
> > > software systems are designed to enforce a particular
> > implicit model of
> > > various situations.
> >
> > There will be many assumptions in almost all references I would ever
> > write down.   That is because I would not have time to write all the
> > assumptions.  Yes, I did assume that my sentence is true for
> > the time of writing, and not for all time.  I hope you got my point
> anyway.
> >
> > Some references require a temporal assumption, like my example above.
> > The addition of this temporal assumption allows me to reduce the number of
> > fields/slots I must use had I must assume "for all time".
> > The addition of assumptions is of course just for textual brevity.  Of
> > course, a formal system would try to avoid these assumptions to
> > maximize reflection.
> 
> The concept of assumptions is terrible. It's simply logically impossible to
> enumerate anything close to "all assumptions", which is why I suggested a
> constructive approach. That is, to build the functions that determine a
> quoted expression's denotation, and have *that* function act as a context
> building-block. That's what my lookup actions in the Slate MOP are doing in
> the most general sense, and I intend to use all possible senses that suit
> it.

Yes, but even *that* function has too many assumptions within it.  This
is not a bad thing, it depends where you start.  I prefer the
hardware/VM instructions as a starting point for a context building
block.  I would like to know your thoughts on this matter in more
detail.  I believe that there must be non-reflective hardware/VM that
encapsulates the infinity of reference assumptions.  It is in this
environment that the tractable number of assumptions can be made about
context, and a reflective environment built.


> > > But the way that it's done in Slate is open and extensible and
> > > meta-programmable. *That's* the difference.
> > Yea, of course!
> 
> Okay, something got through here, then. :)
> What's important about this is that Slate's namespaces are not multi-sets
> (i.e. no duplicate domain values in the lookup function). This directly
> relates to the notion of identity in the object system used to "label" Slate
> objects at any level, and if we want to transcend textual labels, then this
> issue needs to be looked into.

There would be no need to transcend textual labels.  The fact that the
name space is potentially infinite allows for a simple quoting
solution.  


----------------------------------------------------------------------
Kyle Lahnakoski                                  Arcavia Software Ltd.
(416) 892-7784                                 http://www.arcavia.com