Reflection and quotation

[Kyle Lahnakoski]

"RE01 Rice Brian T. EM2" wrote:
> 
> It looks like we got around to agreeing on terms, but I haven't communicated
> my point yet about where I want to develop quotation.

Your experience in standard terminology is sure to be larger than mine. 
If you want to provide a redefinition of terms during a post I would be
more than happy to surrender whatever word(s) I was using.


 (I was actually hoping
> Bill Tanksley or someone would mention something about Joy et al, but I can
> manage). Now if only I can accumulate enough time in the day to put together
> my ideas for this thread. :P
> 
> > From: Kyle Lahnakoski
> > "RE01 Rice Brian T. EM2" wrote:
> > > > From: Kyle Lahnakoski
> > > > 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.
> 
> Yes, but again the enclosing context (the world state) is also an object
> that is a cached function result in this particular view. In other words, I
> can apply the view recursively to containing contexts.

:) 

<SNIP>

> What I'd like is the ability to extend the system of quotation by using it
> to provide new types within the language itself. Of course, to ensure that
> the most appropriate implementation is used, the base representation and
> operations of hardware must be accessible. But essentially, it would be good
> to be able to define syntactic forms for various abstract types and
> collections (sometimes called "comprehensions"... there are papers not just
> on list comprehensions, but also for monads and collections in general).

<sarcasm> Use XML! </sarcasm>

<SNIP>

> The simple issue that all labels must be reducible in all cases to text
> induces limitations that I don't think Tunes should have. For instance, how
> do you textually represent a graphical representation of some kind with
> complex structure (like a bitmap or a schematic or a vector of those)? Of
> course you can counter that argument by requiring all types to have a
> textual name, and then assigning a unique ID for that type (supposedly) by
> concatenating the type name with an index number of some kind. This, by the
> way, is basically the same method of quotation that computer science
> originally inherited from Gödel in that famous text that precipitated all of
> this business about reflection. :) (Yes, I know he used unique
> factorizations of natural numbers.) But it's not enough for Tunes, I
> propose. I could suggest various reasons, but I don't know at what level
> such reasons would be necessary and what reasons would be superfluous, but I
> am sure that a single identifier space (like a textual namespace) for type
> names is definitely inadequate.

Textual representation of objects of any type eh?  My simple answer is
impossible.  :)  I consider human readable text (text that is not
difficult to read from left to right, top to bottom) to be parsable by a
CFG.  Structures that are richer then hierarchical graphs can not be
represented textually.  
Rich structures can only be human readable in 2 dimensions, and this
means visually.

The key words above are "human readable".  All objects can be
serialized, but the inexperienced human mind can not take a
serialization and "see" the important relationships between the elements
of a structure.  XML embodies the ability to represent objects
textually.  All the problems with textual representation show up as
problems with XML.

Once your application is not bound by textual representation, the
indication of object type is simpler.  Self was doing the right thing
when representing objects the way it does.  Issues, like quoting, are
trivial.




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