Reflection and quotation

[RE01 Rice Brian T. EM2]

Once more into the breach! >:)

> From: Kyle Lahnakoski
> "RE01 Rice Brian T. EM2" wrote:
> > > From: Kyle Lahnakoski
> > > 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.
> > 
> > So, how does this help us understand quotation better? How does
> > this help us learn from and transcend the limited forms we have 
> > currently? Obviously, quoting opens up a necessarily(?) available
> > part of the lexer/parser.
> > Another view is that it provides a built-in (set of or kernel of)
> > function(s) for casting the types of objects into basic code types.
> 
> Textual quotation has limits.  I thought that was what you were
> looking for: to extend textual quotation to something more general,
> but still textual.  It is apparent now that you do expect the 
> generalization to be a visual solution.  Visual quotation should be
> called referencing, and like I mentioned in my previous posts, any
> combination of (typed) attributes that uniquely identify an object
> can be considered a reference.  Attributes I mention can themselves
> be references, not necessarily primitive.

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.

> > > 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.
> > 
> > Why human-readable? What's wrong with using a visual diagram to
> > not just represent, but denote (as the primary means of denotation)
> > something linguistically? Of course a whole system will need both 
> > textual as well as visual ways to convey information and denote
> > objects, but I hardly consider textual braces to convey the notion
> > of a set in its most natural sense or generality of definition.
> > 
> > In the Self system, you have a user interface which has both visual
> > (the object-slot relationship is depicted as well as inheritance)
> > and textual aspects to it. The same is true of many other
> > applications, like CAD/CAM systems (which I worked with and on for
> > a while).
> We both agree here, I had mentioned the same: "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." 

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, ...". :)

> > > 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).

> > 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. :)

> 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. ;)

> 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.

> 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

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.

> 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.

> Referencing objects is done through spaces.  Some examples I have now
> are the Table_Space consisting of Database and Class dimensions (for
> each Class(type) there is only one table holding that type per
> database).  There is the instantiation space with Class, Object
> dimensions.  The environment will commonly map the 
> multidimensional user dimension to the Primary_Key dimension for
> internal representation.

"Database and Class dimensions"? These mean absolutely nothing to me. I
think you've loaded your terms with some assumptions that I'm missing. Or
you're too far into database theory for my programming language-based ideas
to relate to.

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

The rest of the stuff just sounds loopy to me. Why Classes and Objects? Why
one table per type? Why tables at all? (After all, isn't a table finite and
a type often *infinite*?)

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.

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. ;)

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.

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 :).

> Again.  What specific problems are you looking at that can not be
> solved?

Chew on the examples I gave above first, please. Most of the examples I
would give stem from them.

Thanks,
~