Reflection and quotation

[RE01 Rice Brian T. EM2]

Here are some more attempts of mine to refine my points:

> From: Kyle Lahnakoski
> "RE01 Rice Brian T. EM2" wrote:
> > 
> > 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.
> 
> Your experience in standard terminology is sure to be larger 
> than mine. If you want to provide a redefinition of terms during
> a post I would be more than happy to surrender whatever word(s)
> I was using.

I'm not really concerned with that. And it wasn't a big issue, either.
Honestly, though, it *does* reflect on the Tunes Glossary, which will be
improved quite soon (by writing through my efforts and a few others, and
technically by Corey Reece and HCF and Tril).

> <SNIP>
> 
> > 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).
> <sarcasm> Use XML! </sarcasm>
> <SNIP>

I was hoping for better feedback than that. ;)
Of course this means I should elaborate. But that will have to wait until I
can get home in a few hours so I can quote papers freely. Actually, some of
the examples I give below seem to address this.

> > 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.
> 
> Textual representation of objects of any type eh?  My simple answer is
> impossible.  :)  I consider human readable text (text that is not
> difficult to read from left to right, top to bottom) to be 
> parsable by a CFG.  Structures that are richer then hierarchical
> graphs can not be represented textually.  
> Rich structures can only be human readable in 2 dimensions, and this
> means visually.

So, how does this help us understand quotation better? How does this help us
learn from and transcend the limited forms we have currently? Obviously,
quoting opens up a necessarily(?) available part of the lexer/parser.
Another view is that it provides a built-in (set of or kernel of)
function(s) for casting the types of objects into basic code types.

Someone (I or a volunteer ;) should analyze these existing types of
functions, perhaps producing a short catalog of various linguistic features
that could be classified as quotation in any sense. Here's an informal list
off the top of my head:
	quotation marks for strings,
	comments in code,
	escapes,
	vector and set notations,
	the obvious list,
	array indexing,
This probably covers most of the broad cases. What should be done (probably
again by me) is to detail what type system level functionality they provide.
Another aspect to catalog is the kinds of syntactic form used by various
languages to express these features. If anyone has exceptional cases to
mention or add to this, it would also help. It would at least add an
interesting aspect to the Language Review sub-project.

> The key words above are "human readable".  All objects can be
> serialized, but the inexperienced human mind can not take a
> serialization and "see" the important relationships between 
> the elements of a structure.  XML embodies the ability to represent
> objects textually.  All the problems with textual representation show
> up as problems with XML.

Why human-readable? What's wrong with using a visual diagram to not just
represent, but denote (as the primary means of denotation) something
linguistically? Of course a whole system will need both textual as well as
visual ways to convey information and denote objects, but I hardly consider
textual braces to convey the notion of a set in its most natural sense or
generality of definition.

In the Self system, you have a user interface which has both visual (the
object-slot relationship is depicted as well as inheritance) and textual
aspects to it. The same is true of many other applications, like CAD/CAM
systems (which I worked with and on for a while).

> Once your application is not bound by textual representation, the
> indication of object type is simpler.  Self was doing the right thing
> when representing objects the way it does.  Issues, like quoting, are
> trivial.

How closely did you look at Self? Its MOP is supplemented by
implementational support of quotation by the system of Mirror objects (see
the Self Programmer's Reference Manual) that its VM provides to reify the
structure of literal types. This *is* a kind of quotation, even though it
doesn't get commonly called this. We need to detail a framework for
dynamically modifying and extending this idea.

Furthermore, if you compare Self with (what I'm trying to do with) Slate,
you'll see that its syntax contains lots of dependencies on static quotation
primitives (like strings and arrays and blocks and such). Of course this is
unfair to Self, since just about every language has this same set of
crutches.

Well, I'm running out of time at work for tonight. Perhaps I'll be able to
add something more once I get home.

Thanks,
~