Reflection and quotation

[Kyle Lahnakoski]

I consider quoting as only a special form of referencing: referencing by
unique 
attribute.  

First I will make a simple, but necessary, distinction.  A function is a
static entity.  Much like in set theory a function can be seen as a set
of ordered pairs, a function can not DO anything.  Performing the
operation that a function specifies is a different concept altogether. 
Furthermore, the code that specifies the function is also a different
concept.  There are many languages that can express the same function. 
A function, as defined above, can be referred to using a variety of
methods.  The simplest is through the use of source code; the code
identifys/specifies a function uniquely.  But we could also a unique
name, or integer ID.  Note these three examples all require a frame of
reference to be effective references.  The source code needs a language
definition, the unique name needs a name space and the unique ID needs a
key space.  Using this unique structure to refer to the function called
referencing.  Specifically: using source code to refer to a function is
called quoting. 

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".  Computers refer to data structures using memory
addresses though pointers.  

Everything appears to be a reference.  In the case of functions: source
code and compiled bytes are both references to the same function object,
but the function object is never realized in the machine.  Every
reference in a machine is really a representation of a reference.  I say
it is a representation of a reference because references need
interpretation to become references.  A representation of a reference is
again a reference of a reference.  Here we see a sort of recursion, and
only a primitive/base case will allow use to make something useful.  It
looks as though Brian has seen this through his use of arrows.    

"RE01 Rice Brian T. EM2" wrote:

> Now, I present some details of various languages' quoting features and the
> drawbacks and advantages of them. First, we of course have Lisp's QUOTE,
> which works on symbols and lists of symbols. Since it's a Lisp function like
> any other (except for being primitively supplied), it can be
> recursively-applied, which is certainly a rare property for a language, and
> a definite Tunes Requirement (TM). However, notice that the way in which
> it's done limits our symbols to not include whitespace and other reserved
> characters. I know that it's the usual Tunes party-line to claim that this
> is just a limitation of the ASCII system, but this ignores a subtle, larger
> issue (I believe). 

> In C, we have a hackish answer to this problem which I
> believe suggests a Tunes way of handling this situation in general. We have
> a finite set of symbols in our current protocol, and not all of them can be
> part of the set of inputs directly, because the protocol outside the quotes
> must be the same as that within (otherwise you can't have your full
> expressiveness within the quotation). So in C (does even Lisp do this for
> string types?) and other languages we reserve things like control characters
> to allow for those characters. But what kind of functionality does this
> provide in general terms? Control characters allow for a limited form of
> recursion of quoting within languages like C. But in Tunes, we need to build
> source objects from more simple object types using generic, flexible, and
> above all, OPEN, functions.

The quoting issue you raise is an ASCII limitation.  As you pointed out,
C solves this problem.  I will go though several iterations of quoting
my name Kyle:
	"Kyle"
	"\"Kyle\""                           <- I escaped my quotes
	"\"\\\"Kyle\\\"\""                   <- Escaping \ and "
	"\"\\\"\\\\\\\"Kyle\\\\\\\"\\\"\"    <- And so on

As a typed data structure, the quoting is much simpler: 

	"Kyle"
	A -> "Kyle"			
	B -> A
	C -> B

"->" is read as "refers to".  We can note that there is an equality
between A and "\"Kyle\"" because they both refer to the same thing. 
ASCII is doing a bad job because it does not have an infinite alphabet. 
C takes care of that, but is ugly.  A second solution uses a method to
define new letters as references to established objects.  Typed data
structures allow the latter to happen quite simply.  Just define objects
that reference.

> Of course, my particular question is "How does this relate to Slate?". In
> Slate, expressions are built out of lookup chains, so every expression is
> just a list of symbols. If we want to build Tunes out of Slate, then this
> has to be at an abstract level, so that whitespace issues and such are
> irrelevant. (Of course first implementations have and will be quite ordinary
> in this sense.) So, in order to produce a Self-style mirror object for our
> source, we could have a Slate object whose slot names are the respective
> indexes of the characters, and whose "state" (as defined by ":" and "^"
> discussed earlier) would be the elements of the character type namespace.
> (These would be first-class Slate objects within another first-class Slate
> object acting as the class/namespace.)

The application to Slate is obvious and unremarkable because it has all
been done before.


> 
> For example, "Foo" would be:
> 
> "Foo"
>  1->'F'
>  2->'o'
>  3->'o'
> 
> (Suggestions for Slate object notation would be appreciated :).
> 
> This is of course just like many common languages where strings are just
> lists of characters. However, since we have an open system for extending
> Slate's type system, (which I have mentioned and am still researching and
> will discuss in a separate thread), we could re-define the quoting mechanism
> in this way. The side-effect is that our method of interacting with the
> evaluator would have to change in a systematic way. I think that being
> conscious of the way in which keyboard interaction is modally-handled is the
> Right Thing for Tunes. (Such as what the keyboard modifiers do, what symbols
> each key maps to, what the timing of keypresses means, etc.)

You mention the use of a concatenative language to specify a path in a
great Slate graph.  One thing I would like to see is how Slate makes new
objects and alters its own graph.  This would be an important aspect to
defining new objects that refer to others and solves the quoting
problem.


> There is also the aspect of uniqueness of identification and the related
> idea of scope that comes into play with modes of interacting with the
> evaluator. This is where those dangerous buzzwords "extension" and
> "intension" come into play, but I don't see this as a great obstacle, as
> long as we approach the subject constructively. For instance, the equality
> relation among objects of a type determines at what level of abstraction
> determines the uniqueness type built from that type. Keep in mind, though,
> that an equality relation over a type can be conceptually separated from the
> type, so in principle you could consider several equality relations and
> therefore several uniqueness types generated.

I am not sure what this paragraph is trying to say.  But I suspect is
very similar to what I have written.


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