[aurelius]

Every single Python project you stated simply proves my point. They are Python compilers of some sort. TXR, on the other hand, is a data processing language implemented in its own lisp which is implemented in C. In other words, TXR is an application of lisp, not just a compiler or interpreter like those Python projects you listed. So, all your examples are irrelevant.

TXR didn't need its own dialect of lisp. So, the question remains: why didn't Kaz use SBCL or CLISP? They're good enough for c.l.l. kooks like him to recommend to everyone else, but why're they not good enough for him to use?

[kazinator]

The kook here is you, and I can prove it: you have a bizarre view that developers should be divided into political parties based on programming language, and code strictly to the party lines. Bizarre views make the kook.

TXR does need its own dialect of Lisp because Common Lisp isn't suitable for slick data munging: not "out of the box", without layering your own tools on top of it.

This is a separate question from what TXR is written in. Even if TXR were written using SBCL, it would still have that dialect; it wouldn't just expose Common Lisp.

That dialect is sufficiently incompatible that it would still require writing a reader and printer from scratch, and a complete code walker to implement the evaluation rules of the dialect. Not to mention a reimplementation of most of the library. The dialect has two kinds of cons cells, so we couldn't use the host implementation's functions that understand only one kind of cons cell. So, whereas some things in TXR Lisp could be syntactic sugar on top of Common Lisp, with others it is not so.

Using SBCL would have many advantages in spite of all this, but it would also reduce many opportunities for me to do various low-level things from scratch. I don't have to justify to anyone that I feel like make a garbage collector or regex engine from scratch.

So, the reasons for not using "SBCL" have nothing to do with "good enough". It's simply about "not mine".

TXR is a form of Lisp advocacy.

TXR is also (modest) Lisp research; for instance I discovered a clean, workable way to have Lisp-1 and Lisp-2 in the same dialect, so any Lispers who are paying attention can stop squabbling over that once and for all.

It pays to read this:

http://www.dreamsongs.com/Files/HOPL2-Uncut.pdf

Why we have Lisp today with all the features we take for granted is that there was a golden era of experimentation involving different groups working in different locations on their own dialects. For example, the MacLisp people hacked on MacLisp, and it wasn't because Interlisp wasn't good enough for them. Or vice versa.

That experimentation should continue.

[aurelius]

> So, the reasons for not using "SBCL" have nothing to do with "good enough". It's simply about "not mine".

Kaz, the C programming language isn't yours either. My point is that Common Lisp is supposed to be a general purpose programming language with power far greater than a primitive language like C, but you chose to implement TXR in C simply because C makes it much easier for you to accomplish your goal than Common Lisp. I'm just trying to point out the obvious, which nobody from c.l.l. seems willing to admit.

[lispm]

It's a tool with some embedded kind of Lisp dialect. There are zillions of it.

> why didn't Kaz use SBCL or CLISP?

Why should he? He can do whatever he want. I personally don't care at all about what he does. Why are you? Kind of strange obsession with comp.lang.lisp. Are you one of the trolls posting there?

> They're good enough for c.l.l. kooks like him to recommend to everyone else, but why're they not good enough for him to use?

Probably he did it to annoy real programmers like you?

[aurelius]

> > why didn't Kaz use SBCL or CLISP?

> Why should he?

Kaz invested a bunch of time implementing a whole new backquote implementation for CLISP, but it's still not good enough for him to use CLISP to implement TXR? It doesn't make any sense!

Any right-thinking programmer should care about inconsistencies such as this. If I'm evaluating a programming language, and I see someone in its community writing their own language implementation to support an application that could've easily been written using one of the standard language implementations, then it looks to me like the standard implementations aren't mature enough or trustworthy enough for me to use for my application. Not only that, but it suggests that maybe this particular language isn't as good as its advocates claim, especially if I have to drop back down to C in order to meet certain requirements (e.g., portability, speed, wider understanding, etc.).

But any right-thinking programmer already knows that lisp is not worth wasting any time on. It's dead, and people like Kaz, and projects like TXR, are going to make sure it stays that way.