Reflection and quotation

[Kyle Lahnakoski]

"RE01 Rice Brian T. EM2" wrote:
> 
> I can understand how visual implies references ( as an intuition, and *only*
> at first glance), but I was *not* pointing out visual methods as the
> totality of where quotation can go. Visual interfaces were only an example
> to illustrate a direction. Besides, simply talking in terms of references
> makes the idea of quoting seem trivial when it definitely is not, as our
> experience with languages and interfaces evidences.

I really do not know what you are trying to do then.  If you want to
investigate the rich intersection of references and languages then so be
it.  But I believe you are making the analysis unnecessarily complicated
by adding the language dimension to referencing.  There are an infinity
of languages, and you want to generalize quoting in all of them.  As we
both agreed, quoting requires context.  What if the context of the quote
in a particular domain specific language was designed to be easy to use,
and not necessarily consistent with your canonical view.  

> Again, though, the Tunes project doesn't just require a *level* of
> expressiveness, like 2-d diagrams vs. linear text (or parse trees). There
> certainly are things that can't be expressed by 2-d diagrams... take the
> field of rational numbers and try to distinguish it syntactically from a
> generic field or, more easily, the reals. Maybe you can do it with an
> *infinitary* 2-d diagram, but then that's like saying you can syntactically
> describe the natural numbers by "0,1,2,3, ...". :)

"distinguish it syntactically" is confusing.  I would find "distinguish
it logically" much easier.  Maybe I can suggest "The rationals" and "The
reals" as naive symbols to distinguish the two sets.

> > > > 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.
> > > How closely did you look at Self? Its MOP is supplemented by
> > > implementational support of quotation by the system of Mirror
> > > objects (see the Self Programmer's Reference Manual) that its VM
> > > provides to reify the structure of literal types. This *is* a kind
> > > of quotation, even though it doesn't get commonly called this.
> > > We need to detail a framework for dynamically modifying and
> > > extending this idea.
> > My fault for not being clear.  I only meant to refer to Self's visual
> > object representation (Morphic).
> 
> I *know* what you were referring to, but I believe that it's an inadequate
> metaphor for more general ideas that Tunes should deal with. For example,
> the object-with-state metaphor underlies the way that the Self UI works. How
> do you model the number 4? Sure, it has behavior, and this behavior can be
> *represented* with objects and slots, but the concept of editing such an
> object breaks down immediately because 4 relies on a context; its behavior
> has meaning only because of the relevance of other similar objects. This is
> why the notion of meta-object that is possible in Self is not adequate for
> Slate (thinking of meta-objects as implementations for their objects, and
> therefore lambda-closures).

You want to edit 4?  What would you like to do to it?  This weaving of
behavior and objects is a side effect of not having a normalized
representation of that specific domain.  If 4 has attributes, like
behavior, then somebody did bad design work.

> > > Furthermore, if you compare Self with (what I'm trying to do with)
> > > Slate, you'll see that its syntax contains lots of dependencies on
> > > static quotation primitives (like strings and arrays and blocks
> > > and such). Of course this is unfair to Self, since just about every
> > > language has this same set of crutches.
> 
> > Maybe I will tell you about my "quotation" system.  Maybe you can help
> > me understand what you are looking for by providing a problem that my
> > system can not solve.
> 
> "providing a problem that my system can not solve" suggests that you have a
> hammer and would like to know what nails it cannot apply to. I'll counter
> with providing examples of things which aren't nails. You get to decide what
> I'm arguing. :)

OK. :)

> > There is a concept called a Space.  Each Space has zero or more
> > dimensions.  Each dimension has its own range, not necessarily
> > distinct.  Any object that is in this space will have a value
> > (coordinate) in each one of the dimensions.  The set of
> > dimension/coordinate values is unique for each object in the space.
> 
> Right off the bat, you're assuming a static type system as a basis (tuples
> of numbers... reals perhaps?). So in my book you've already lost. ;)

Yes, there is a certain static portion to my system.  It does not mean
the whole system is static.  To build something dynamic there are a few
steps involved:  
	1) Form the idea about what to build.  
	2) Decide on an initial static representation of those
	   ideas (hopefully context insensitive down to the level
	   of the machine).  
	3) Use that static representation for implementation.
	4) Use the reflection routines to declare 2nd level 
	   forms for those ideas in terms of the first; setting
	   up bijections.
	5) The bijection between the first and of the 2nd level forms
	   can be used to put make native optimizations    
Any dynamic system will still have to rest on static structures. 

> > Example of 2D Matrix Space:  We assume the matrix is 3 columns by 4
> > rows.  We can specify any element on the matrix by indicating the
> > ordered pair (r, c).
> 
> How does this relate to the language level, though? I mean, what sort of
> grammar would this concept fit into? *This* is an example of why quoting is
> different from referencing, even on an abstract level.
> 
> e.g. for 2d matrix space "A", you're suggesting identifying objects with "A
> x y". In other words, the expression "A x y" is the *name* of the object.
> NOTE: later on my confusion about other parts of this concept suggest that
> you mean "A (x y)" to be the name of objects.

Like we both agreed, the context of the quote will have to be taken into
account.  Therefore each domain specific language will have its own most
useful representation for one of these elements.

> > Every object is a member of the one dimensional Primary_Key space
> > where each object is given a unique value.  Since objects are allowed
> > to multiply instantiate.  They can be members of Primary_Key space
> > and other user defined spaces.  It should be obvious why this space
> > deserves mention.
> 
> Okay, so one "space" is by definition maximal?
> i.e. there exists Space X, such that for all objects Y, Y is in X

Yes.  I do this for convenience (step 3).

> BTW, the dimensionality issue seems irrelevant, since it just seems an issue
> of currying space-object membership pairs. Also, the database term of
> "Primary_Key" seems provincial.

I knew you would bring this up.  I agree that only one or two dimensions
is all that is needed.  Two dimensions embodies the ordered pair
primitive.

> > Example continued:  Each element is an object, therefore it is also a
> > member of the Primary_Key space.  That means each element can also be
> > referred to by a key value.
> 
> I interpret this to mean that you're describing a system where one "type" or
> "namespace" can/must be able to express the identity of all objects in the
> system.

Yes.  But only for the objects that have been resolved to the
Primary_Key space.  There can exist many objects that have not been
resolved to this space because the system is not "interested" in them.

> But to give you the Benefit of a Doubt, I'll offer what I think you're
> trying to say:
> 
> "Referencing objects is done through spaces."
> This is really ambiguous, and you really should provide an example
> expression. My above example of the matrix-element naming scheme seems to
> contradict this. At one level, I'm thinking this is like my namespaces idea
> where "space1 space2 space3 object" gives you what you want, but then I
> realize you're speaking totally from a table-driven perspective so you only
> have single-level nesting of objects within spaces (i.e. "space object").

Yes, there is only a single level of nesting.

> But then the dimensionality "feature" crops up again, and you have to have
> "space (x y z)" which invokes *quotation* implicitly. :)

I do not understand this last sentence.

> Finally, you're completely ignoring the fact that some objects in every
> system *are* the data, and I don't just mean those darn static types
> provided with systems, like hardware integers and strings and such. At some
> point you will want to make an object whose representation is an ordered
> pair, but whose semantics are vastly different from an ordered pair, like
> Complex numbers. (I culled this example from "A Functional Pattern System
> for Object-Oriented Design.) When you do, you'll find that the
> object-with-state notion of just about every popular language out there just
> croaks and dies: you have to live with hacks to get it done.

If you believe in extensionailty, then I see your problem.  But many
languages can make the distinction between two classes that have the
same type.  May you give me a year or author for that paper?  I would
like to see how contrived the problem is.  ;)

> When you have the situation I describe above, applying a type of quotation
> form to it will result in lots of problems, like not being able to optimize
> dynamically for the type because the grammatical formalism for it that the
> compiler consumes will not express the semantics of the desired type in a
> way that will handle things naturally. You'll have redundant type checks
> happening all the time with no way to intelligently explain to the compiler
> why it need not do them. This, I believe, violates the principles of Tunes
> and illustrates why a new language is needed.

> > The Variable_Space deserves special mention because it embodies
> > referencing.  Classes have field definitions.  Every object that is an
> > instance of a particular class must have a single variable(slot) for
> > each of the defined fields.  We see that for any single object/field
> > pair there is at most a single variable in existence.  This explains the
> > Object and Field dimensions of a variable.  Since variables are objects
> > they also have a Primary_Key dimension.  I like to write variables as
> > triples: (Key, Object, Field).  Variables embody the concept of a
> > reference, therefore every variable points to some other object.  This
> > can be extracted by using the getValue() function.  I do not allow
> > variables to be 4-tuples (Key, Object, Field, Value) because they ARE
> > the value.
> 
> I just have to respond now with a big "HUH?". Your entire system implicitly
> depends on a reference system which is "base reality" and means you're
> totally relying on a *single* low-level type system to get your leg-work
> done. This is acceptable to most people who ignore the fact that you can't
> just allocate every object in main memory. At some point, you have to
> allocate those integers, or you're just doing more hack-work. ;)

I do not know how this relates to "allocat[ing] every object in main
memory".  

The allocation of integers need not be done.  My application
*represents* integers as lists of boolean-like values.  Both of these
values are just objects devoid of attributes.  Now, this representation
is only my initial preferred representation (step 2).  Once the
reflective system is complete other representations can be made and
declared in terms of the first (step4).  Either one can become the
native representation for the system (step5). 
Furthermore, the representation of integers already has two views.  The
second being the VM int, which expects a specific limited format of an
integer.

> To be more to the point, your *TUPLES* are part of another language, the
> implementation language. This means that I believe you're just transferring
> any issues you would have to deal with in the subject language into the
> implementation language, which means you're not dealing with it at all from
> the Tunes perspective, AFAIK.

It would appear that way, but it is not so.  Maybe we just differ on
terminology again.  The subject language was certainly relieved of doing
quoting except by simple symbolism of variables.  But the implementation
language is significantly simpler.  My quoting was pushed into the
system of objects and classes.  There I made the Space_Class objects
that describe the action of a space: essentially describing a database
index, with selectivity of one (step4).  

> You know, this is getting really too complex for the actual concepts
> involved. May I suggest you learn to express things in a good Lisp like
> Common Lisp or Scheme? The syntax exposes most of the concepts pretty
> naturally, and I happen to find it quite nice when an indentation-based
> sugaring for it already exists (that Sugar package for Scheme... no
> parentheses :).

You want us to speak in Scheme? ;)  How would you be able to distinguish
between logical concepts and anomalies of the language?  Besides,
debugging is harder than clarification.


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