Reflection and quotation

[RE01 Rice Brian T. EM2]

> -----Original Message-----
> From: Kyle Lahnakoski [mailto:kyle@arcavia.com]
> Sent: Thursday, August 17, 2000 7:21 PM
> To: RE01 Rice Brian T. EM2
> Cc: 'tunes@tunes.org'
> Subject: Re: Reflection and quotation

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

That's odd. I thought that Tunes defined attributes in terms of functions.
:)

Indeed, right on the HLL Semantics page
(http://www.tunes.org/HLL/semantics.html), attributes are listed as unary
functions. Now, if you want Tunes goals, then meta-programming has to be
considered, and higher-order attributes simply *are* functions, whether you
like that or not.

In fact, many languages do this in order to provide "object-orientedness".
And if memory serves me correctly, ML has higher-order references, since it
can hold a reference (not a pointer) as a variable, which can in turn also
be a higher-order functional term.

Attributes, in other words, are just artifacts of a view on a system that
supposes the notion of state implicitly.

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

This seems a totally arbitrary distinction to me, especially when you
consider higher-order functional programming. For instance, for any two
functions f and g, I could "define" a new function object using composition:
f*g or f(g) or even f+g. These functions at the language level exist only
for the duration of the context they produce: for example, for "f(g)(x)",
f(g) does not persist beyond the function call, but both f and g naturally
do.

And a function when considered in its enclosing context surely *does* have
state and can be muted, otherwise there's no point in programming such a
system (unless you care to express your programs in a calculus without any
notion of reference at all).

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

But in Tunes, "source code" had better be a Tunes object, which means there
are various views of it, that for example consider it as an aggregate or a
stream or a generic function or whatever else you please. Besides, I believe
the notion of source code you're using is just an artifact of the
single-representation notion of code that languages are currently tied to,
which means *non*-reflective (lexically, syntactically, and semantically).

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

> Computers refer to data structures 
> using memory
> addresses though pointers.

This last sentence is horrible. Am I supposed to think you mean the
processor itself? In that case, it's totally oblivious to data structures,
which makes the sentence meaningless. This is a totally low-level set of
semantics. Data structures are objects, and talking about their low-level
allocation and maintenance is just placing it within the context of a linear
type system. Of course, this allows one's references to be the pointers'
values themselves. In other words, I could have a Slate object act as a
linear memory namespace, whose slot names are what you would call the
"pointers" or "references". I could name them at *various* levels of
abstraction, and at the meta-level (the meta-object implementation of the
namespace) this would be provided by *functions* (which dynamically generate
behavior of slots based on the results of a function applied to the slot
name). Now do you see what I mean? I could label memory at the bit-level or
at the word-level or even abstractly using a segment-based scheme of
dividing the memory area which uses segments of variable size.

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

I think my reply concerning functions versus attributes as references should
make things clearer between us, especially with what you're trying to say
here (which sounds like higher-order functions in disguise).

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

The problem is that we want a functional notation for this.

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

But the way that it's done in Slate is open and extensible and
meta-programmable. *That's* the difference.
 
Sorry, I'll reply to the rest later tonight, I promise. But the last
sentence you made is correct, and the part about how Slate creates and
rewrites its object graph is what I will address next.


Thanks,
~