Re: [Txr-users] TXR, similar tools

[Kaz Kylheku]

On Mon, 25 Apr 2011 08:27:50 -0500, Russell Adams
<address@hidden> wrote:
> Having reviewed TXR, I adore what I see!
> 
> I must ask, are there similar tools (ie: language libraries for Perl
> or Scheme) that inspired TXR?

The inspiration is shell "here docs" and 
pattern matching / unification. Also, the patch utility
(patch performs line-based pattern matching on context
lines to find where a hunk applies). I don't use Scheme or Perl,
but I have a lot of experience with Common Lisp. Internally in Txr,
symbols and lists work more like Common Lisp than like Scheme.
(Lists are terminated by the nil symbol, and can be improper).

The basic idea was that: whatever we can synthesize by substitution
into templates, we ought to be able to analyze likewise,
in any language.

For instance, in C, we have the crude printf to format text, and a
roughly analogous scanf to pull apart formatted text. If you
squint your eyes, they are similar. E.g. print two numbers
separated by a space:  "%d %d", x, y .   Scan two numbers
separated by whitespace "%d %d", &x, &y.

In Lisp we can use unification libraries to match between
nested list structures, and use backquote to generate new list
structures.

It's irksome how in shell programming easily we can generate
entire text files with here docs, but we can't reverse the
effect in the same way when we need to.

I developed early versions of Txr while working on a project
that involved applying patches to an entire installed system.
However, the patches had to be rolled out to installations
which might contain variations: for instance, differences
in an /etc/fstab file, and the like.

I needed to generate patch files from templates, substituting pieces
of text into the actual diff context lines, and the - and + lines.

I used here docs to generate the patches, but I found it irksome
to extract the pieces of info to interpolate, even though it closely
matched the shape of the patches being generated. I could imagine:
what if we could pretend we are applying this patch, find where
in the file it matches, and then actually pull out the nonmatching
pieces of text to update the patch so that it does actually apply.

I.e. I essentially wanted a robot that could fix up patches
based on looking at a base file that is somewhat different
from the original.

So I started working on Txr; and early versions were put to
immediate use on that project.

> Text extraction is a frequent chore of mine, and I'll have to see what
> I can apply TXR to!

If it gets mind-bending, post here.

Cheers ...