Re: sexp-aware theory of patches and "meta common lisp"


nalle...@xxxxxxxxx wrote:
I read an interesting paper on designing a version management system
for XML documents

http://www.goshaky.com/publications/master-thesis/XML-Version-Management.pdf

I also found another one but haven't had a chance to read it

http://citeseer.ist.psu.edu/chien00version.html

Anyways, I've always thought it would be cool to extend darcs' Theory
of Patches (http://www.darcs.net/manual/node8.html) to work with trees
of data. Ideally it would enable node-sensitive diffs.

Since lisp code is naturally in the form of a tree, it would enable
you almost immediately to generate reports from a repo of code like
"user X has modified the definition of class NAME and function FOO"
and with some work things like "user X has added a :INITARG option to
the slot BAR in the definition of class NAME and changed the
definition of the function FOO", etc.

As swell as they are, however, CL's extendible syntax and read macros
are, thoroughly prevent the system described above to work with
arbitrary portable code, since sexps have to be READ from a file, and
in doing so lose data from the #+, #-, #. forms in the file (I wonder
if this is one of the things Gregor Kiczales was thinking about when
he talked about the inverse relation between the strength of a
language and the ease of making development environments for it:
http://bc.tech.coop/blog/060709.html).

It would be great to have an orthogonal, extendible "meta common lisp"
language/package that could describe CL code solely for the purpose of
tool/IDE integration (think CSS to XML, but for metadata). So if you
called READ-META you'd get some abstract sexp object tagged with info
about when it's supposed to be EVALed, and under what conditions,
etc., and info about the sexp's "semantic" meaning (is it a part of
the body of an anonymous function or a quoted list that may or may not
be returned by a macro). It would also be a formal way to extend CL's
documentation facilities with out screwing with the standards and make
it easier to extend IDEs to support embedded languages.

For now

Nick

Glancing over this last post, I see that I am clearly losing my
control of the English language... My apologies for the (lack of)
grammar and repeated words, I was interrupted several times while
writing it...

.

Relevant Pages

  • Re: sexp-aware theory of patches and "meta common lisp"
    ... for XML documents ... I've always thought it would be cool to extend darcs' Theory ... Also check out the patch facility on the Lisp Machine. ... language and the ease of making development environments for it: ...
    (comp.lang.lisp)
  • sexp-aware theory of patches and "meta common lisp"
    ... I read an interesting paper on designing a version management system ... for XML documents ... I've always thought it would be cool to extend darcs' Theory ... language and the ease of making development environments for it: ...
    (comp.lang.lisp)
  • Re: Why return None?
    ... > That extend doesn't work for strings and tupples is irrelevant. ... If lists were being designed from scratch today, ... A "greenfield design", an entirely new language designed from scratch, ...
    (comp.lang.python)
  • Re: A new paradigm
    ... I'm sure non-mv tools ... manipulation language and other utilities which work "inside the system". ... Simon further said "I would prefer to extend the dictionary to add to the ... datatype classes to expose higher level methods and objects. ...
    (comp.databases.pick)
  • Minix 2.04 problem adding systemcall
    ... I have tried to extend the ... MM with an extra function(a simple function foo() without arguments that ... always succeeds). ... changed files to implement foo: ...
    (comp.os.minix)