4 ms·
I could have done that, but I couldn't be bothered to look up the interpolation strings for format (yes, we have it), or the one level flatten function, and the
by qwertyuiop924 10y ago
I could have done that, but I couldn't be bothered to look up the interpolation strings for format (yes, we have it), or the one level flatten function, and the splicing unquote is less efficient than cons in this case. But yes, in real code, I'd probably go in that direction.
There is one key difference between my code and yours: in mine, the functions, values, and symbols referenced in the macro are automatically renamed, thus guaranteeing no namespacing conflicts. Due to the way the CL package system works (IIRC), CL provides almost the same guarantees, at least in this case. But it is an important semantic difference.
And it is the Common Lisp. Despite how you may feel, Scheme, Clojure, PicoLisp, NewLisp, Racket, Interlisp, LeLisp, EuLisp, and others are as much a Lisp as CL.
- lispm 10y agoProcedural macros were introduced to Lisp twenty years before CL existed and quasiquotation around ten years before CL existed. > and the splicing unquote is less efficient than cons in this case Not sure why that should be the case and why it even matters.
- qwertyuiop924 10y agoTrue, 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 10y ago> 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 10y agoWell, then it's slowing down compilation. And yes, most schemes have them. I was talking about Picolisp, Newlisp, and Kernel, which don't.
- lispm 10y ago> 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 10y agoWell, 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 10y ago> 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/expand.scm 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.
- 10y ago