I mostly agree but fwiw, the usual counterargument on #2 is that those should be language facilities instead, which allows them to be carefully designed and then taken advantage of by the compiler. For example, in Racket (formerly PLT Scheme) you have: http://docs.racket-lang.org/guide/contracts.html
This is a terrible example for your argument, because contracts in Racket are entirely implemented as a library, thanks to the power of -- you guessed it -- macros. In fact, just about everything in Racket: the class system, the generic function system, the unit system, the type system, the serialized continuations, the pattern matcher, keyword arguments -- all of those are implemented with macros.
The problem with this argument is, that you will never have the amount of independned development on every feature. There are usually only a relativly small amount of people at the core of a langague.
If I want a new feature in the language is very hard to get it in and once its in its in. With macros diffrent people can do there own thing and indepently develop it.
Look for example at core.match, in every other language something like it would have been a new language feature. Clojure now has a state of the art pattern matcher without Rich or anybody doing anything.
I'm not sure how well that specific example works. Are contracts built in to the language on a fundamental level, or are they just part of the standard library? Given that they're not included in racket/base, and given how flexible racket's core is, I would guess the latter, but I'm not sure.
"Are contracts built in to the language on a fundamental level, or are they just part of the standard library? "
One of the points of Lisp is that that difference doesn't matter.
But besides that, in this case it couldn't possibly matter. You write contracts for your functions. If they're violated at runtime you'll get a clear error that stops execution to contain damage, and assigns blame to the contract violator. At what point in that process does it matter whether contracts are "built into the language"?
To be clear, I'm not suggesting it's an important question per se.
_delerium presented an argument that the things people do with macros should be implemented as language facilities instead. Ve used racket contracts as an example.
I was saying that if racket contracts are not implemented as language facilities, it's not a very good example.
