Oh it can be. Typically, if I need to do some text transformation or extraction, I start by getting sample data and renaming it to a .txr suffix. Then just generalize that data into the TXR pattern that matches it and gets out what is needed.
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,
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.
It's a very ugly language, I don't think anyone is going to disagree there.
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.
My first reaction was also that it didn't look very clean. But after some admittedly cursory comparison of how you'd do something in TXR to a few existing scripts I have (some Perl, some awk, and some chaining Unix utilities), it doesn't look terrible, and maybe even good. I should emphasize this is based on like 30 minutes of looking at it though, not serious knowledge of how TXR works.
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.
Yes, all those at-signs make it look like a combination of lisp and perl, which probably won't excite too many people.
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.
The at sign in the TXR pattern language is that way because TXR can match reams of literal text.
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.
TXR has some really cool features and seems very well suited to the domain. If you're going to dismiss perfectly good tool just because it "looks ugly" then you're just being unprofessional. And if it's "awkward to type" you can always write a transpiler if you really need it, or more likely a couple of macros/snippets for your editor.
