Re: [Pika-dev] xl as config file, programmatic manipulation pitfall

[Thomas Lord]

    > From: Jeremy Shaw <address@hidden>

    > It is my suggestion that the xl comments be designed so that programs
    > can be programmatically transformed without screwing up the comments.

Absolutely.

Comments should be first-class syntactic elements and should be
explicitly "attached" to something else in the parse to which the
comment refers.

Additionally, comments have an internal and mostly-opaque-to-tools
concept of formatting.  For example, if my comment contains an
"ascii art" table of keywords and values, then all source-level
transformations that preserve that comment should also preserve 
the ascii art, no?

In some sense, these issues are largely orthogonal to the parts of xl
i've been concentrating on: semantics and operational model.
Floating multiple syntaxes over the abstractions I've been working on
is certainly possible and probably, imo, desirable.   Perhaps some
will have support for structured comments and others won't?

In any event, I think you are absolutely correct that config files in
particular would benefit from structured comments.

Another issue is whether or not to add explicit *internal* structure
to comments.   For example, if part of a comment is a "doc string"
that an interactive system might want to translate into a help
message: can that doc string part of the comment be explicitly
specified at the xl syntax level rather than at the level of some
post-processor that parses the strings an xl parser has identified as
a comment?   What about that hypothetical ascii-art table: should it
be generically parsable in such a way that xl code can do an ASSOC
lookup in the table?

Yet another issue is code->code transforms.  Structured comments
complicate those.  Do you have any thoughts about how to write, for
example, a pattern-matching/template-based-rewrite system that handles
structured comments gracefully?  In this regard: in lisp, code also
puns as generic lists of lists and atoms and constant vectors and
structures.   Thus, generic list manipulation routines are meaningful
and handy when applied to certain subsets of code input.   Can one add
structured comments without losing that property?   To illustrate, 
suppose I have a code fragment like:


        for (x = 1; 

It's easy enough to imagine a pattern matcher that could be programmed
to recognize:

        for (x = _;

(abstracting away the "1") but would the same pattern also match
a hypothetical construct like:


        for (  /* start at 1 not 0 because ... */->(x = 1);

where my little pseudo-syntax is intended to indicate a comment
attached to a particular subexpression?

Maybe we need to reincarnate Bach and teach him programming to figure
out how to handle all these puns at once :-)

-t