Hacker News Reader

Comment by lkrubner | Hacker News Reader

Good lord, I would go insane if I ran into a bug like this:

"We've built an esoteric application (even by Lisp standards), and in the process have hit some limits of our platform. One unexpected thing was heap exhaustion during compilation. We rely heavily on macros, and some of the largest ones expand into thousands of lines of low-level code. It turned out that SBCL compiler implements a lot of optimizations that allow us to enjoy quite fast generated code, but some of which require exponential time and memory resources. "

View on HN

Actually these errors are relatively easy to spot and and often there are solutions for that. Sometimes a compiler might need to be hacked on. The good thing: the compiler is written in Lisp and debugging is possible.

The more nasty errors are lurking for example in the GC... there we move into C and assembler land...

Most platforms have nasty errors. With popular platforms one can hope that many of these have be found and somebody has fixed them already. With language/runtimes which are no so widespread in production one is more likely to find these problems oneself. Especially in more complex runtimes.

Yeah, but that's something you need to be prepared for. Such bugs happen in literally every platform (for instance, I had similar trouble with the JVM). So the question is not how to avoid them, but how to cope. Usually, there are 2 ways:

- workaround

- investigation (and in this case, if you're on a closed platform you're busted)

It'd be a Hell of a lot more interesting than the millionth time looking into a bug caused by invalid input into a non-validated form in an ancient CRUD intranet app.

At least those are usually pretty quick to fix.

That makes the optimistic assumption that someone will fix them.

You can write C++ template metaprogramming code that will send your compiler into coma, if you're not careful. Code that pushes the boundaries is bound to push through them occasionally.

You know, starting a paragraph by "We've built an esoteric application", would you expect what followed to be a simple bug?

Write an "esoteric" app and you'll start hitting the limits of your platform.

I dont really understand the downvotes... I agree with you would go nuts.

My two cents, if your macro is expanding to thousands of lines of code, your doing something wrong I think. I would expect Macros to expand out to a few lines of code which might have function calls that themselves may contain however many lines of code... but expanding to thousands of lines INLINE via macros seems wrong.

I have pointed to the call-with-* style which is a general "best practice" for that (it's even mentioned in Google CL Style guide). However, expanding to low-level stuff also has it's benefits for a clearly delimited space (mainly, performance) if you know what you're doing

Some macros expand to a lot of code, especially when doing more in-depth transformations such as those performed by core.async in Clojure where they transform standard sequential code into a state machine with exactly the same semantic but with the added ability to execute, yield and resume like a coroutine.

I assume their macros do compilation of an expressive DSL to efficient low level code, as one would expect in their domain. So keep in mind that this is something pretty fancy you can pretty much only do with Lisp (or by writing a full blown compiler).

Have you seen any recursive macros?

https://github.com/lispgames/cl-sdl2/blob/ec64831109a17b0dda...

You're getting a lot of pushback on this, but I think it's a legitimate question at the very least. In this situation I would wonder whether some procedural abstractions could be introduced to cut down the size of the expansions.

And before anyone jumps on me -- I have 35 years of Zetalisp and Common Lisp experience and have written some pretty hairy sets of macros. There might turn out to be no easy way to make the expansions smaller, but there's nothing wrong with asking the question.

Yeah it's fairly easy to fix this (and you can even do it without unwinding the stack!). There are tons of sbcl global variables which you can tweak on-the-fly.

Reply on news.ycombinator.com