Reflection and quotation

[Kyle Lahnakoski]

"RE01 Rice Brian T. EM2" wrote:
> 
> > -----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.

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.



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

It depends on what you mean by exist.  If you mean exist in terms of
being explicitly referenced in a machine, then I would agree.  On the
other hand I like my functions to always exist in a giant function
space.  f, g, f*g, fog anf f+g always exist, it is only a matter of
whether the machine is referring to those functions at any given
moment.  



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

Of course.  I was trying to say that above and below.  Many of our
simple references mean nothing without the contextual baggage needed to
interpret them.  I was unclear trying to portray the fact that the
baggage is also part of the reference.



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

I agree. 



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

There will be many assumptions in almost all references I would ever
write down.   That is because I would not have time to write all the
assumptions.  Yes, I did assume that my sentence is true for the time of
writing, and not for all time.  I hope you got my point anyway.  

Some references require a temporal assumption, like my example above. 
The addition of this temporal assumption allows me to reduce the number
of fields/slots I must use had I must assume "for all time".  The
addition of assumptions is of course just for textual brevity.  Of
course, a formal system would try to avoid these assumptions to maximize
reflection.



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

Absolutely.  Note that state is primitive construction wrt the machine
hardware.  The functions you propose are only accessing the state. 



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

Yea, maybe.



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

And like I said, the method used now is the creation of reference
objects that can be used with relatively short names in the source
code.  Of course you need state for that.



> But the way that it's done in Slate is open and extensible and
> meta-programmable. *That's* the difference.

Yea, of course!



> 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 

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