Reflection and quotation
Fri, 18 Aug 2000 09:00:42 -0400
"RE01 Rice Brian T. EM2" wrote:
> > -----Original Message-----
> > From: Kyle Lahnakoski [mailto:firstname.lastname@example.org]
> > Sent: Thursday, August 17, 2000 7:21 PM
> > To: RE01 Rice Brian T. EM2
> > Cc: 'email@example.com'
> > 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
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
> 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).
> > 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
> > 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).
> > > 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.
Kyle Lahnakoski Arcavia Software Ltd.
(416) 892-7784 http://www.arcavia.com