5 ms·

Nah man,macros are the bee's knees! Being able to add new constructs to a language is neat. My favourite examples are match.scm - a pattern matcher that produce

by bjoli 7y ago

Nah man,macros are the bee's knees! Being able to add new constructs to a language is neat. My favourite examples are match.scm - a pattern matcher that produces zero overhead code - and racket's for loops, which are just regular macros. Being able to add features like that is amazing. Clojure'sarrow syntax? No problem. Python's list comprehensions? Can be done! A library for Pattern matching? Many to chose from! Pattern matchers that were added to other languages as libraries are often weird to use. Match.scm has the same syntax as cond or case.

taeric 7y ago
Unpopular opinion that doesn't even disagree with you. LOOP is superior to rackets for loops. The minimizing and maximizing constructs are surprisingly readable.
- bjoli 7y ago
  I agree to some extent. To get the same power from rackets loops you have to do a lot more work using for/fold. I have an implementation of rackets loops for guile scheme, and I'm currently rewriting it to allow arbitrary transformations in the loop clauses. Say I want to write a Fibonacci loop, currently I can't do this: (for/list ((a :first 0 :then b) (b :first 1 :then (+ a b))) a)
- bjoli 7y ago
  I forgot to mention that loop requires a lot of mutation, which sort of sucks in scheme world where you can use multi-shot continuations and ruin the fun. There are loop implementations for racket (which produce decent code and all that), but they are rarely used.
Yxven 7y ago
Lisp always sounds cool to me until someone starts talking about macros. What's it like inheriting a lisp code base, finding out its full of homemade macros like list comprehensions, and that they're not documented? Inheriting a code base is always scary, but I feel like it kicks it up a notch when your predecessors can customize the language itself. Are my fears justified?
- kazinator 7y ago
  > What's it like inheriting a lisp code base, finding out its full of homemade macros like list comprehensions, and that they're not documented? If such a macro is used in more than two places, it's generally a relief that the author did that instead of doing copy and paste by hand. The author had some coding idea, and formalized it into a little robot that writes that idea, which has a name. Even if that thing isn't accompanied by documentation, it can serve as a kind of documentation to what it's doing. Code is going to be full of homemade functions that are not documented; whether they are functions that write code at compile time, or whether they are run-time functions, is kind of a minor concern.
- bjoli 7y ago
  Macros look the same as functions in lisp, the only difference is that you can't pass them as function arguments. Unless there is a bug in the macro you just spend the same time understanding the macro that you would understanding a function. Most macros are just simple syntactic abstractions that expands simple code to more lines of relatively simple code to avoid boilerplate. Very rarely do people write complex beasts without documentation.

by bjoli 7y ago

taeric 7y ago

Unpopular opinion that doesn't even disagree with you. LOOP is superior to rackets for loops. The minimizing and maximizing constructs are surprisingly readable.

bjoli 7y ago
I agree to some extent. To get the same power from rackets loops you have to do a lot more work using for/fold. I have an implementation of rackets loops for guile scheme, and I'm currently rewriting it to allow arbitrary transformations in the loop clauses. Say I want to write a Fibonacci loop, currently I can't do this: (for/list ((a :first 0 :then b) (b :first 1 :then (+ a b))) a)
bjoli 7y ago
I forgot to mention that loop requires a lot of mutation, which sort of sucks in scheme world where you can use multi-shot continuations and ruin the fun. There are loop implementations for racket (which produce decent code and all that), but they are rarely used.

Yxven 7y ago

Lisp always sounds cool to me until someone starts talking about macros. What's it like inheriting a lisp code base, finding out its full of homemade macros like list comprehensions, and that they're not documented? Inheriting a code base is always scary, but I feel like it kicks it up a notch when your predecessors can customize the language itself. Are my fears justified?

kazinator 7y ago
> What's it like inheriting a lisp code base, finding out its full of homemade macros like list comprehensions, and that they're not documented? If such a macro is used in more than two places, it's generally a relief that the author did that instead of doing copy and paste by hand. The author had some coding idea, and formalized it into a little robot that writes that idea, which has a name. Even if that thing isn't accompanied by documentation, it can serve as a kind of documentation to what it's doing. Code is going to be full of homemade functions that are not documented; whether they are functions that write code at compile time, or whether they are run-time functions, is kind of a minor concern.
bjoli 7y ago
Macros look the same as functions in lisp, the only difference is that you can't pass them as function arguments. Unless there is a bug in the macro you just spend the same time understanding the macro that you would understanding a function. Most macros are just simple syntactic abstractions that expands simple code to more lines of relatively simple code to avoid boilerplate. Very rarely do people write complex beasts without documentation.