Reflection and quotation

[RE01 Rice Brian T. EM2]

I'd like to discuss an interesting aspect of Tunes that previously had not
explicitly occurred to me. That is reflection on the quotation function of a
language. As a preliminary survey, I'd like to know if any of you all know
of languages (experimental or otherwise) that have interesting forms of
quotation, or even possible a notion of quotation which can be dynamically
modified.

To be precise, I mean any set of functions working between the type system
associated with the input to the evaluator and other type systems (commonly
ASCII text and such). In Lisp, there is of course the special form (or is it
just a primitive function?) QUOTE which takes in symbols or lists of symbols
and returns the equivalent CONS tree. (As of the present moment, the web is
unavailable to me, so if some kind person would paste in the CLHS or R5RS
specifications of QUOTE, it would be appreciated :). I've been following
discussions in the Concatenative Languages mailing list, so I know of some
interesting issues that Bill Tanksley and Brent Kerby have been working with
in Joy, Conk, and such.

Basically, if we consider EVAL = UNQUOTE o APPLY as a basic equation for
describing this aspect of the language implementation, we have a general
means of thinking about the problem. Of course, for Tunes we always want to
have useful ways to apply (sic) partial evaluation of parameters on the
evaluating context (to produce different contexts). So this means that our
APPLY will have varying semantics: for instance, we could curry it with
additional parameters or use the Tunes principle of quotienting to have it
consider its source input at a different level (say, instead of textual
strings, abstract tokens). This isn't anything unusual... it's just the
factoring out of the lexer from the parser-backend combination. So in a more
general sense, we're just considering the generic ability to re-factor the
implementation.

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.

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

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

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.

Quick example over strings: "foo27" and "foo29" could be considered as
unique modulo "foo*"-ness up to 27 vs. 29 or unique modulo "foo2*"-ness up
to 7 vs. 9. A more generic example would consider representations of
rational numbers and their appropriate equality. Of course, most high-level
languages deal with that at a satisfactorily abstract level, but it's one
that's chosen in a static way. This suggests that our open implementation of
quoting be generic enough to allow quote functions which are non-standard.

Well, that's enough of rambling. I'm interested in any thoughts or examples
you could provide on this (in its entirety or just in part). Of course I'm
also researching other areas that tie into this (particularly type
specification), so don't think that I've focused on one narrow issue (since
I'd be ignoring the other important but undeveloped Tunes issues).

Thanks,
~