As an example, I was doing some kernel work and needed patches to conform to the kernel's "checkpatch.pl" script. Unfortunately, this thing outputs diagnostics in a way that Vim's quickfix doesn't understand; I wanted to be able to navigate among the numerous sources of errors in the editor.
First I looked at the checkpatch.pl script hoping that of course they would have the diagnostic output in one place, right? Nope: formatting of messages is scattered throughout the script by cut-and-paste coding.
TXR to the rescue:
Sample output:
WARNING: line over 80 characters
#279: FILE: arch/arm/common/knllog.c:1519:
+static void knllog_dump_backtrace_entry(unsigned long where, unsigned long from
WARNING: line over 80 characters
#321: FILE: arch/arm/include/asm/unwind.h:50:
+extern void unwind_backtrace_callback(struct pt_regs *regs, struct task_struct
WARNING: line over 80 characters
#322: FILE: arch/arm/include/asm/unwind.h:51:
+ void dump_backtrace_entry_fn(unsigned long where,
WARNING: line over 80 characters
#323: FILE: arch/arm/include/asm/unwind.h:52:
+ unsigned long from,
Quick and easy TXR to the rescue: @(repeat)
@type: @message
#@code: FILE: @path:@lineno:
@(output)
@path:@lineno:@type (#@code):@message
@(end)
@(end)
Result (redirected into errors.err, loads with vim -q): arch/arm/common/knllog.c:1519:WARNING (#279):line over 80 characters
arch/arm/include/asm/unwind.h:50:WARNING (#321):line over 80 characters
arch/arm/include/asm/unwind.h:51:WARNING (#322):line over 80 characters
arch/arm/include/asm/unwind.h:52:WARNING (#323):line over 80 characters
arch/arm/include/asm/unwind.h:53:WARNING (#324):line over 80 characters
arch/arm/kernel/unwind.c:352:ERROR (#337):inline keyword should sit between storage class and type
The nice thing is that we know what the above does when we revisit it six months later.That being said, it has some intriguing features that I'm not going to dismiss. I work with COBOL on a daily basis, so I'm not going to say no to a new language just because it's ugly. There seems to be a lot of utility here.
But I'd say that data munging is inherently ugly. I don't really see myself using this as the next tool to write clever algorithms that will stand the test of time, but if you offer me this as a stand-in for the usual shell-script/awk/sed/perl/printf/regexp mess you need for ad-hoc file transformations, I'm suddenly listening.
This is hard to show in small examples, so small examples become dense with the notation. Just like, say, tiny examples of HTML become a dense soup of tags.
Note that TXR Lisp doesn't have the at signs. You can write a pure TXR Lisp program by wrapping the whole file with @(do ... ).
TXR looks a lot better with syntax highlighting; unfortunately, this only exists for Vim. On the other hand, the syntax highlighting definition file for Vim is quite good.
One part that seems nice is that it handles multi-line constructs in a way that isn't horrible. Perl and awk have a big complexity jump once you go past one-line records, and most of the traditional Unix utilities just don't handle them at all (stuff like cut/join/sort only works on single-line, delimited records). Since constructs like Perl's while(<INPUT>) stop automatically doing the Right Thing once you get multi-line records, the usual next stop is that you're manually maintaining a state machine.