2 ms·

No. Good idiomatic Lisp code might use some macros for domain-specific applications, and if those aren’t increasing readability, then they have no place in prod

No. Good idiomatic Lisp code might use some macros for domain-specific applications, and if those aren’t increasing readability, then they have no place in production code. A few prominent macros we do use: - A macro to define a string lexer (aka tokenizer) for a programming language - A macro to define peephole optimizations of linear instruction code - A macro to define friendly looking bindings to Fortran functions - A macro to generate highly optimized complex double precision matrix arithmetic code for inner loops We do use “standard” macros, mostly from the ALEXANDRIA library. But these are idiomatic and have been used since at least the 80s. (Some of these are macros that On Lisp defines from scratch.)

eru 7y ago
That sounds mostly like you'd want to be using something like functions, but Lisp ain't a strong enough language, so you have to use macros? (Just for comparison, in Haskell you would probably do most of these without macros. They do have (something like) macros in Haskell, though. They are not quite as natural as in Lisp, mostly because of differences in syntax.)
- reikonomusha 7y ago
  It’s true that in a lazy functional language you can get by with fewer syntactic extensions for common programming patterns, but it doesn’t, at the end of the day, actually solve the problem of syntactic extension or code generation.
  - eru 7y ago
    It's not just laziness, though that helps. It's also bunch of other idioms and features. (I've programmed in a strict variant of Haskell for a while.) Ideally, a language like Haskell would actually be total by default; ie all computations are finite. For those computations, the compiler can freely choose evaluation strategies without affecting semantics. For potentially infinite calculations, you'd go into a mode that's somewhat similar to how IO is segregated in existing Haskell. (There's some more complications about things like infinite event-loops, that can be solved very similarly; and for some things you might want the user to provide proofs that they are indeed finite, instead of just overriding the compiler's judgement with an unsafe cast.)

eru 7y ago

That sounds mostly like you'd want to be using something like functions, but Lisp ain't a strong enough language, so you have to use macros? (Just for comparison, in Haskell you would probably do most of these without macros. They do have (something like) macros in Haskell, though. They are not quite as natural as in Lisp, mostly because of differences in syntax.)

reikonomusha 7y ago
It’s true that in a lazy functional language you can get by with fewer syntactic extensions for common programming patterns, but it doesn’t, at the end of the day, actually solve the problem of syntactic extension or code generation.
- eru 7y ago
  It's not just laziness, though that helps. It's also bunch of other idioms and features. (I've programmed in a strict variant of Haskell for a while.) Ideally, a language like Haskell would actually be total by default; ie all computations are finite. For those computations, the compiler can freely choose evaluation strategies without affecting semantics. For potentially infinite calculations, you'd go into a mode that's somewhat similar to how IO is segregated in existing Haskell. (There's some more complications about things like infinite event-loops, that can be solved very similarly; and for some things you might want the user to provide proofs that they are indeed finite, instead of just overriding the compiler's judgement with an unsafe cast.)