3 ms·

Yes but there is also abuse and or complexity that doesn't make it easy. One of the classic examples for me at least is OCaml's Camlp. For Lisp like languages i

by agentgt 10y ago

Yes but there is also abuse and or complexity that doesn't make it easy. One of the classic examples for me at least is OCaml's Camlp. For Lisp like languages it is easier to have a macro language but for typed languages I think it becomes far more difficult both to implement and understand. A lot of people don't realize that Java offers a macro/preprocess like system (APT) and it is even sort of hygienic (an example project is Google's Auto [1]). APT is not that powerful but it gets you quite far and going back to OCaml the new ppx language extension is actually fairly similar (ie annotation processing instead of a complete macro/preprocessing language). .NET has something analogous but even more powerful (IIRC as well as the whole access to the AST aka LINQ style). > Then you get IDE plugins for writing boilerplate (for, say, JEE). Then you end up with a XML preprocessing pass that writes Java code (XDoclet). 2001 called and wants it example back :) . Yes APT didn't exist for a while. Tangental but XDoclet sort of reminds me of Go's very weak annotation system. And again It takes time to get a macro/preprocessing engine right particularly for typed languages. e.g. Rust has had some fair challenges getting this right and even their macro system is not completely hygenic IIRC. [1]: https://github.com/google/auto https://github.com/google/auto

outworlder 10y ago
> ... but for typed languages I think it becomes far more difficult both to implement and understand. I don't think that types are the issue but rather that such languages were not designed with macro systems in mind from the very beginning. Some added complexity is unavoidable, of course. > A lot of people don't realize that Java offers a macro/preprocess like system (APT) and it is even sort of hygienic (an example project is Google's Auto [1]). I didn't. Will look it up. > 2001 called and wants it example back I had to use that abomination as far as 2005. I understand that's a dated example, but it is the best example of that slippery slope taken to its extremes that I could think of. It is also a good example in the sense that it used XML instead of expressing itself in the original language. As such, it is also a nice illustration of Greenspun's Tenth Rule.
- ruste 10y ago
  I was also completely unaware that Java had a macro system. I'll have to check that out.
  - agentgt 10y ago
    Calling it a macro system is probably a stretch of the word :) but if you check out APT you should also check out the far sexier Java Agents [1] which is code that changes other code during runtime (ie alters structure and provides meta programming). [1]: https://docs.oracle.com/javase/7/docs/api/java/lang/instrument/package-summary.html https://docs.oracle.com/javase/7/docs/api/java/lang/instrume...
- agentgt 10y ago
  > I don't think that types are the issue but rather that such languages were not designed with macro systems in mind from the very beginning. Some added complexity is unavoidable, of course. I thought I had a reference somewhere to back that up but can't find it. However I do massively agree having had better planning early in the language could have prevented some serious headaches (its one of the reason I have concerns about Go). That being said there are some that think macros are inherently code smell particularly if your language has lazy evaluation. e.g. Haskell programmers can go quite far with out having macros. That is controlling evaluation may free the need of a majority of macros (ignoring the verbosity saving aspects).

by agentgt 10y ago

outworlder 10y ago

> ... but for typed languages I think it becomes far more difficult both to implement and understand. I don't think that types are the issue but rather that such languages were not designed with macro systems in mind from the very beginning. Some added complexity is unavoidable, of course. > A lot of people don't realize that Java offers a macro/preprocess like system (APT) and it is even sort of hygienic (an example project is Google's Auto [1]). I didn't. Will look it up. > 2001 called and wants it example back I had to use that abomination as far as 2005. I understand that's a dated example, but it is the best example of that slippery slope taken to its extremes that I could think of. It is also a good example in the sense that it used XML instead of expressing itself in the original language. As such, it is also a nice illustration of Greenspun's Tenth Rule.

ruste 10y ago
I was also completely unaware that Java had a macro system. I'll have to check that out.
- agentgt 10y ago
  Calling it a macro system is probably a stretch of the word :) but if you check out APT you should also check out the far sexier Java Agents [1] which is code that changes other code during runtime (ie alters structure and provides meta programming). [1]: https://docs.oracle.com/javase/7/docs/api/java/lang/instrument/package-summary.html https://docs.oracle.com/javase/7/docs/api/java/lang/instrume...
agentgt 10y ago
> I don't think that types are the issue but rather that such languages were not designed with macro systems in mind from the very beginning. Some added complexity is unavoidable, of course. I thought I had a reference somewhere to back that up but can't find it. However I do massively agree having had better planning early in the language could have prevented some serious headaches (its one of the reason I have concerns about Go). That being said there are some that think macros are inherently code smell particularly if your language has lazy evaluation. e.g. Haskell programmers can go quite far with out having macros. That is controlling evaluation may free the need of a majority of macros (ignoring the verbosity saving aspects).