source distribution

Tril dem@tunes.org
Thu, 29 Oct 1998 14:07:00 -0800 (PST)


[Regarding Jecel's message of Oct 21, subject: source distribution.]

Let me just clarify about source distribution.

TUNES does not have source in the traditional meaning.  Traditionally
source is a textual representation of a program or object.  TUNES operates
entirely on the level of abstract syntax, and source is just a linear way
of encoding syntax.

When you share programs/objects between TUNES systems, they will negotiate
a representation for the abstract syntax being shared, which may be a
different representation every time.  

When you use TUNES, the user interface is a view onto the abstract sytax,
and is customized to view it in different ways. 

If you want to convert existing languages to TUNES, there must be a
description of that language written in TUNES.  That allows TUNES to
manipulate and recognize the language.  Once you import some C source (for
example) into TUNES it stores it in TUNES format, but each object is
constrained to conform to C limitations.  You may remove these limitations
and reorganize the code to be more appropriate for TUNES.  (Perhaps even
keep a record of what you do, to allow easier conversion back to C)

To convert from TUNES to a current system (say to generate a C program to
approximate some TUNES objects), you work with the system to decide how to
map abstract syntax into a strict linear syntax.

If you wish to communicate with TUNES using something resembling
traditional source, you could intermix syntax from different languages
(perhaps with directives inserted in the text to switch from one to the
other --Fare's choice), or design your own.  

TUNES is intentional, which means when you design a program, and it
requires some functionality from the system, it describes what needs to be
done, instead of using a symbol to refer to the function.  The way this
works is that the system can separate the function from the purpose of the
function.  (Specification of an algorithm is matched when resolving
dependencies for installation of a package.  Not the name of the
algorithm.)  So we need a rich specification system.. and that's what we
are working on.  [this paragraph could use some peer review to help revise
it! Thanks!]

David Manifold <dem@tunes.org>