Question about extensible HLL syntax

[Brian T Rice]

On Wed, 5 Feb 2003, Michael Conrad wrote:

> I had some questions about the HLL.  On the HLL Principles page
> (tunes.org/HLL/principles.html) you mention that the language syntax
> that the programmer is typing will be extensible to possibly encompass
> all other programming syntaxes, and automatically rewritten to work
> with the system, or something like that.

Yep, lots of hand-waving. :) What I'm looking at to support that include
an architecture for handling multiple types of syntax trees and scoping
semantics as well as syntax abstraction, particularly Maude's Meta-Parser
(see http://cliki.tunes.org/Syntax%20in%20Maude). No, I don't have all the
answers, and I know that Fare definitely doesn't (he wrote all that, I
just edited it).

> For reflection, would you be able to reflectively look all the way up
> to the syntax, or only examine as far as the HLL representation?  I
> guess the real question is whether the syntax extensions are really
> *added* to the HLL, or whether you would just have a syntax
> interpreter that would convert your code into accepted HLL that could
> be used by the system.

"look all the way up to the syntax" doesn't really make sense to me. You
seem to _not_ mean the Abstract Syntax Tree. But later you're talking
about adding syntaxes or canonicalizing / normalizing it. My response
right now is that we're trying to do the former; my evidence is in the HLL
architecture area: http://tunes.org/HLL/architecture.html#parse ...

Generally, we'd like to turn expressions into some kind of object tree
that expresses things that are listed in "Standard Basic Constructors"
(the primitives page that I wrote to Fare about yesterday). As for a way
to debug this tree, we'd probably need a standard facility to print them
out (graphically or textually), which is not really an HLL issue (more
like an Interface with maybe some Migration). However, I could see how
this would give the impression to the user of "normalization", and there
obviously would be some standard for these tree node objects to follow so
that the semantics behind it can be "pluggable".

If you're wondering if it will be SEXP, we probably won't do that except
on very first tests because it would be easy, but there's no univerality
in SEXP for syntax. Pretending that positions of arguments mean something
is a concrete syntax issue, not an abstract one.

> Also, when the code is being automatically transported from system to
> system, what format will it be transmitted in?  If the original
> language were used, then the recipient would need the same syntax
> extensions to interpret it.  If the auto-written official HLL were
> sent, then what if someone wanted to modify the source code?
> Wouldn't some of the ideas/intentions of the original programmer be
> lost after the rewrite?  This might be a moot point, since if the
> second user were interested in modifying the code they could just ask
> the first person for the original source code and then install the
> syntax extensions themselves.  Mostly I am wondering if there would be
> any incompatibility between systems with different syntax extensions.

Great question. That's entirely what the Migration subproject is about.
You're right: whatever language is used, whether a programming language or
a data encoding, will have those components like syntax, dispatch, and
such implied, so the other system needs those modules installed, to say
nothing of other libraries called by the code.

About "auto-written", I guess you mean the syntax trees; in that case,
there'd be some formatting information that wouldn't matter to making the
code work. However, Fare did address this kind of information in an
example about active annotations... See:

http://tunes.org/HLL/general.html#bindings

under the Examples listing, and there's a little bit more at the end of
the page. (I'll see if I can clean that up.)

So really it would be extra information about laying out the code that
would be "tagged" onto the syntax tree nodes as needed, or if there's an
automatic layout algorithm that someone used, the "whole tree" would be
tagged that way. The way Migration deals with it is that these attributes
are only moved across the network on demand, or even that it wouldn't be
migrated, but the remote user who changes the code ships back the changes
which the first user incorporates. Pretty-printing vs. careful manual
arrangement (of various kinds) is a matter of aesthetics, though, so I
don't think there's an ideal solution for this, but it could probably be
done well enough. Does that make sense?

> I'm just trying to get a handle on how the whole system would
> function.  Sorry if the questions sound silly.

No problem. They really weren't silly at all.

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