[qwertyuiop924]

True, but as my code aptly demonstrated, procedural macros don't work the same jb all Lisps. Some Lisps don't even have them.

AFAICT, splicing unquote has to traverse the entire result list. Not super relevant in this case.

I don't know why I picked cons, honestly. I guess it just fit ny mental model of what was happening better.

[lispm]

> AFAICT, splicing unquote has to traverse the entire result list. Not super relevant in this case.

Especially since it is usually done once at compile time.

> Some Lisps don't even have them.

Even most Scheme implementations have them.

[qwertyuiop924]

Well, then it's slowing down compilation.

And yes, most schemes have them. I was talking about Picolisp, Newlisp, and Kernel, which don't.

[lispm]

> Well, then it's slowing down compilation.

My five MIPS Lisp Machine did not care. My Lisp implementations on a several hundred times faster processor don't care either.

These languages you list don't have macros.

[qwertyuiop924]

Well, then, if you don't have macros, then you don't have procedural macros, which was my point.

And I didn't say it was a legitimate reason to use cons. I said it technically had better performance. As I stated above, the real reason I used it is because it fit my mental model of what was happening.

[lispm]

> Well, then, if you don't have macros, then you don't have procedural macros, which was my point.

Trivially.

Anyway, I don't consider them to be Lisp dialects anyway. They are new languages, Scheme dialects, scripting languages with parentheses, whatever. The name 'new'LISP says it already.

> I said it technically had better performance.

You thought it had, without actually knowing it.

    CL-USER 36 > (let* ((bar '(1 2 3))
                        (baz `(foo ,@bar)))
                   (eq bar (rest baz)))
    T

So it's not copied and no traverse is needed.

What actually is traversing the code is your IR-macro mechanism. Twice. -> ir-macro-transformer. Which makes it slower both in the interpreter and the compiler.

https://github.com/bnoordhuis/chicken-core/blob/master/expan...

Traverses the code, then calls the handler, traverses it again...

Btw., the code won't win any beauty contests.

[qwertyuiop924]

Not considering them to be Lisp is ridiculous. Picolisp is closer to Lisp 1.5 than CL is. CL took many ideas from Scheme, and vice versa. The claim that CL is The One True Lisp is tenuous at best, and absurdly ridiculous at worst. It's like a Catholic claiming that they're the only true Christian religion (not a great analogy, but not the worst in the world). It also, quite frankly, given how these languages, particularly PicoLisp, fit every definition of Lisp I've heard, takes us straight into No True Scottsman territory. Haggis, anyone?

It's good to know that splicing unquote optimizes for that case in Lisp. I wasn't sure, and so assumed the general case. In any case, that's not the reason I didn't use it, as I've explained multiple times now.

Yes, I know ir-macro does code traversal. Yes, sc-macros are more elegant. But that's the mechanism we picked, And I have no issue with it. Furthermore, it doesn't traverse all the same code twice. It traverses the inputs and the outputs.

>Btw., the code won't win any beauty contests.

...Says the CL user. Actually, I agree, it won't. But it works, it's reasonably clear, and it doesn't do anything obviously stupid. It's okay.

...Unless you're talking about my code. You want me to clean that up? Okay. I will.

  (define-syntax debug
    (ir-macro-transformer
      (lambda (x i c)
        (let ((exprs (cdr x)))
          `(begin
             ,@(map (lambda (expr)
                      `(printf "~A: ~A~%" ,'expr ,expr))
                  exprs))))))

We still have to bind our args by hand, because it's Scheme, but it's not too bad.