Reflection and quotation

[RE01 Rice Brian T. EM2]

It looks like we got around to agreeing on terms, but I haven't communicated
my point yet about where I want to develop quotation. (I was actually hoping
Bill Tanksley or someone would mention something about Joy et al, but I can
manage). Now if only I can accumulate enough time in the day to put together
my ideas for this thread. :P

> From: Kyle Lahnakoski
> "RE01 Rice Brian T. EM2" wrote:
> > > From: Kyle Lahnakoski
> > > 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.
> > 
> > That's an interesting way to look at it, and we obviously agree
> > beyond the level of terminology. However, I think I need to add one
> > minor point to this: when I speak of state or attributes as based on 
> > functions, I also mean that I don't distinguish between "accessing
> > state" and what a function does.
> > This is roughly similar to what Self and Smalltalk allow (and much
> > more similar to Lisp object systems) in that accessors are
> > syntactically indistinguishable from other functions on the object
> > in question. One of the ideas (hidden albeit) in the idea of the
> > Tunes orthogonally-persistent store is that state is just caching
> > (memoization, if you will) of function values.
> 
> That is interesting.  But it appears that the state of a single variable
> is being pushed into a larger world state that is doing the caching.

Yes, but again the enclosing context (the world state) is also an object
that is a cached function result in this particular view. In other words, I
can apply the view recursively to containing contexts.

> [Omitted thread about user-choice functions and preserving information.]

> > > 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 and f+g always exist, it is only a matter of
> > > whether the machine is referring to those functions at any given
> > > moment.
> > 
> > I'd like to mean both, of course (since both are needed by computer
> > languages). In one case, I want my contexts to denote objects that
> > specifically define what that object can do. In other cases, I'd
> > like the object to act as a container for all objects of a specific
> > type or specification. In the latter case, a hook from the lookup 
> > function in the meta-object allows those objects to be generated and
> > cached on-demand.
> 
> It appears you are mentioning the classic difference between implicit
> and explicit sets, or in other words, classes and formal sets.  Maybe
> you have more insight into this matter than I do.  If so may you
> elaborate?

I could. There are really several ways to look at the idea:
 (1) Algebraically, you have inductive and co-inductive characterizations
(due to the ideas of category theory) (there are quite a few CS research
papers on that.)
 (2) You have your class theory vs. your inductive set theory, where class
theory includes things like ZFC and variations on those axioms (logic texts
cover this fairly well.)
 (3) You have the functional programming or game-theoretical approach to it,
which is relatively new AFAIK. This is where you can encode the axiom of
choice and its uses as the postulation of a function that takes a certain
set of known variables (or no variables at all) and the process of
characterizing a domain (proving things) is done in an interactive game
format, where two players have opposing goals and the proof is in the play.

All of this is too involved for this thread, but it's obviously something
I'm deeply involved in.

*NOTE*: I intentionally omitted the long interaction about references and
such, because I don't think it was leading in the right direction. I'll
attempt here to explain what kind of direction I wanted to go with this:

> From: Youlian Troyanov [mailto:youlian@intelligenesis.net]
> > (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 :).
> 
> FROM R5RS:
> 
> 4.1.2. Literal expressions
> (quote <datum>) 	syntax
> '<datum> 			syntax
> <constant> 		syntax
> (quote <datum>) evaluates to <datum>. <Datum> may be
> any external representation of a Scheme object (see sec­
> tion 3.3). This notation is used to include literal constants
> in Scheme code.

This agrees with the basic idea I suggested that EVAL = UNQUOTE o APPLY. But
there is implicit baggage with Scheme (and other languages)...

> (quote a) => a
> (quote #(a b c)) => #(a b c)
> (quote (+ 1 2)) => (+ 1 2)
> (quote <datum>) may be abbreviated as '<datum>.The
> two notations are equivalent in all respects.
> 'a => a
> '#(a b c) => #(abc)
> '() => ()
> '(+ 1 2) => (+12)
> '(quote a) => (quote a)
> ''a => (quote a)
> Numerical constants, string constants, character constants,
> and boolean constants evaluate ``to themselves''; they need
> not be quoted.
> '"abc" => "abc"
> "abc" => "abc"
> '145932 => 145932
> 145932 => 145932
> '#t => #t
> #t => #t
> As noted in section 3.4, it is an error to alter a constant
> (i.e. the value of a literal expression) using a mutation pro­
> cedure like set­car! or string­set!.

Now, this function is nice because it "just works". However, it implicitly
relies on the existence of the static type system of strings, numbers,
lists, and symbols. Now, I don't want the Slate language to need this kind
of basis. I'd like to say that there's an important class of languages that
are being ignored that are more general than the kind of language that Slate
is, but it's hard to characterize what hasn't been previously developed.

What I'd like is the ability to extend the system of quotation by using it
to provide new types within the language itself. Of course, to ensure that
the most appropriate implementation is used, the base representation and
operations of hardware must be accessible. But essentially, it would be good
to be able to define syntactic forms for various abstract types and
collections (sometimes called "comprehensions"... there are papers not just
on list comprehensions, but also for monads and collections in general).

(Back to the discussion with Kyle...)
> > > > But the way that it's done in Slate is open and extensible and
> > > > meta-programmable. *That's* the difference.
> > > Yea, of course!
> > 
> > Okay, something got through here, then. :)
> > What's important about this is that Slate's namespaces are not
> > multi-sets (i.e. no duplicate domain values in the lookup function). 
> > This directly relates to the notion of identity in the object
> > system used to "label" Slate objects at any level, and if we want
> > to transcend textual labels, then this issue needs to be looked into.
> 
> There would be no need to transcend textual labels.  The fact that the
> name space is potentially infinite allows for a simple quoting
> solution.  

It does allow for a simple quoting solution, but then I'm not looking for
the minimum required function to supply the quoting basis necessary for
useful programming. If that were true, then I would be satisfied with using
simple quotation marks (" ") or Lisp's QUOTE.

The simple issue that all labels must be reducible in all cases to text
induces limitations that I don't think Tunes should have. For instance, how
do you textually represent a graphical representation of some kind with
complex structure (like a bitmap or a schematic or a vector of those)? Of
course you can counter that argument by requiring all types to have a
textual name, and then assigning a unique ID for that type (supposedly) by
concatenating the type name with an index number of some kind. This, by the
way, is basically the same method of quotation that computer science
originally inherited from Gödel in that famous text that precipitated all of
this business about reflection. :) (Yes, I know he used unique
factorizations of natural numbers.) But it's not enough for Tunes, I
propose. I could suggest various reasons, but I don't know at what level
such reasons would be necessary and what reasons would be superfluous, but I
am sure that a single identifier space (like a textual namespace) for type
names is definitely inadequate.

Thanks,
~