3 ms·
You are thinking about this wrong ... and it’s not your fault, because everyone (a large subset of lispers included) thinks about this wrong. You can approach l
by abrax3141 7y ago
You are thinking about this wrong ... and it’s not your fault, because everyone (a large subset of lispers included) thinks about this wrong. You can approach lis programming as normal programming, if you like, but that’s not the right way to approach lisp. The way to approach lisp is to answer the following question: If there was a way I could wave a magic wand, and a special purpose programming language would be created just for my problem, what would it look like? Lisp macros are that magic wand. This seems abstract, but it’s not. Really, take your favorite problem, imagine a programming language (aka. DSL) that perfect for that problem. Write down what it would look like. (The one constraint is that the top level has to be in sexpr format, but even that's not deeply required!) Now use macros to translate your fantasy into whatever implements it algorithmically. Poof! You’re a lisp hacker!
- kazinator 7y agoI'm sorry, but that's only a good way to approach Lisp programming when you know everything that your language comes with, and are sure that none of it provides a good representation for the problem. Otherwise, the way to approach Lisp programming is the same as with any other language: how can the existing syntax and library features (such as macros!) be orchestrated to solve this problem? Which kinds of macros would be useful will become apparent during development. You often don't know what language features may be nice to have until you have worked in that problem domain. Lisp programming sometimes happens without knowing what the ideal language of the problem domain would look like; you don't know that upfront to just it down and make macros for it. Secondly, there may be third-party libraries for the problem domain. For instance, if you're sure that the problem domain requires solving goals stated as queries over logical predicates, that doesn't mean you have to implement your own Prolog in macros. So the priority is roughly: built-in macros > stable third-party macros > experimental/own macros.