Daniel Ross introduction

[Tril]

Hi this is Tril, the list admin.  I am posting these two messages to the
list on the behalf of Daniel Ross.  I have taken the liberty of formatting
them nicely.  Enjoy!

From: "Daniel Ross" <danross@acm.org>
To: <review@tunes.org>
Subject: Hello, all
Date: Mon, 24 Apr 2000 19:16:42 -0700

I'm new to TUNES, and I am making the arrogant move of posting before 
reading everything.  Please forgive my audacity.

I suggest an alternative approach to the language issue.  Do not attempt 
to define a single underlying language.  Instead, pick some problem or 
application area, think really hard about how to implement the 
application, and describe the implementation as abstractly as possible.  
Invent whatever language conventions or formalities are best suited to 
the abstract description of the solution of this particular application, 
without worrying about generalizing to other applications.  Then pick 
some construct in the language you have created, and treat it as an 
application, and apply the process recursively.  What you wind up with 
is a multiplicity of languages, each one tailored to its specific 
application.  Abstraction has been maintained as much as possible, so 
comprehension of the goals to be achieved is not obscured by 
implementation details.  (Incidentally, that is my objection to all 
current object-oriented languages ... the classes and methods still are 
described in languages cluttered with implementation details, such as 
C++.)  The translation of what you have written will not have one single 
binding time from high level to low level.  Instead there will be a 
multiplicity of binding times, as abstractions are incrementally made 
more concrete.  Eventually in the progression of stating implementations 
of simpler and simpler constructs, the implementation will be so simple 
that it reasonably can be coded in some standard language which already 
has been implemented by somebody else.  That terminates the recursive 
simplification for that particular construct.  When all recursive 
construct simplifications have been thus terminated, you have the code 
to implement the original application.

Summary of concepts:

    Maintain abstraction as long as possible

    Multiplicity of specialized languages, many created for just 1
application without attempting generality, and containing only enough
constructs to solve the problem immediately at hand

    Recursive simplification, each step as small as possible in order to
maintain abstraction as long as possible while still making some progress
toward a concrete implementation

    Multiplicity of binding times

    The more abstract representations are the data for their immediate
recursive simplifications.  The distinction between code and data blurs,
or disappears altogether.  Eliminate the old computer science maxim of
cleanly separating code and data.  It is wrong when the "code" is
sufficiently abstract.  It is correct only when the "code" is cluttered
with implementation details that obscure the underlying algorithm. 


From: "Daniel Ross" <danross@acm.org>
To: <review@tunes.org>
Subject: elaboration
Date: Tue, 25 Apr 2000 01:31:25 -0700

I think I should elaborate just a bit on what I am proposing.

The conventional approach to language design is to create an underlying 
language with enough capability for extension to satisfy all anticipated 
future needs.  Whatever decisions are made at the outset, will limit 
generality of expression for the entire lifetime of the project.

I suggest starting by describing just what is needed, and no more, to 
implement each application as it arises, freely inventing language in 
which to state that description.  Gradually work your way from the 
abstract to the concrete by recursively applying this approach.  
Eventually terminate the recursion by describing in a previously 
existing, implemented language (or languages).

I owe this approach to William M. McKeeman, although he may not 
recognize or agree with my modification of his ideas.