RFC: TUNES Specification Pre-Pre-Draft

[Brian T Rice]

Well, there doesn't seem to be too much in the way of feedback just yet,
so I thought I'd draw out some issues and perhaps provoke some opinions
and hopefully technical responses.

One of my main concerns is the form of a document that tries to
express at least semi-formally what we are trying to enable within this
project. I mentioned before that I tried to draw a bit from the Common
Lisp hyper-document for the ANSI specification, but of course it's a
totally different set of issues ultimately. First, CL defined a set of
behaviors to expect from an existing family of lisp's, while TUNES sets
out to define some maximal coherent set of concepts and tries not to say
too much about how it's done. Second, CL is, despite its nature, really a
single language and a few ways of thinking about things certainly
predominate.

So in section 1 I tried to explain this, and that part seems to work out
decently. However, the next section tries to explain the separation of
TUNES issues into aspects, and the separation seems to be decently clear,
but the contents sort of mix together. E.g., I have terms and types mixed
together, which is a bit confusing. Actually, that's a case where I would
have done better with a more-expressive tool. I believe that TeXmacs or
just raw latex editing would allow me to distinguish glossary entries, so
I may move to that.

If you then look at the choice of the elements that I put into the
sub-sections, you'll see some personal bias about the naming of types. In
some cases, it's from my own writing added to the TUNES static site, while
in the Interface and Migration section, I took some license in using
CLIM or Morphic terms in what could be made a generic sense. What do you
think about these?

There are also the operations, which are supposed to cover big-picture
actions that the spec would have to talk about later on.

"Later on" also concerns me. Should I add further sub-sections to the
Aspects areas (basically the sub-projects) or define a later chapter 4
called, say, Elements, where each sub-system, like required type-system
abstractions, has its own section?

Keep in mind that we have whole areas to cover like what needs to be
expressed about (side-)effects and annotations. This factors in to
satisfying our requirements for version-awareness, distributed publication
and versioning, and all of that.

We even have to toy with where partial evaluation and other related topics
come into this, because they're required, but we need to know what's
minimally needed to make sure we can do all that generically.

And, oh yes, it needs to be abstract. =) Someone has to be able to follow
the spec and not notice implementation details creeping through. Doesn't
this sound fun? :-)

Seriously, if you joined to be part of something great, this is how to do
it. Give it some thought and share what you think. But do try to be
precise in your questions and discussions. Thanks!

-- 
Brian T. Rice
LOGOS Research and Development
mailto:water@tunes.org
http://tunes.org/~water/