tag:blogger.com,1999:blog-6454006.post1317181908145666190..comments2024-01-16T14:32:49.175+00:00Comments on Arcane Sentiment: These are a few of my favourite macrosArcane Sentimenthttp://www.blogger.com/profile/04144052171693893368noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-6454006.post-2053227729122809702013-09-16T18:31:42.117+00:002013-09-16T18:31:42.117+00:00Producing source-level error messages is indeed ha...Producing source-level error messages is indeed hard (it requires keeping source locations in the ast, like Racket), but it's not very pressing, because macroexpansion-level error messages are (surprisingly) usually pretty transparent.<br /><br />Does unreadable overuse of macros really happen in the wild, or only in speculation? I've seen plenty of unmaintainable code-mazes made out of classes, and functions, and C++ templates, and mere conditionals — but never out of macros.Arcane Sentimenthttps://www.blogger.com/profile/04144052171693893368noreply@blogger.comtag:blogger.com,1999:blog-6454006.post-35429277877443991572013-09-16T03:58:39.456+00:002013-09-16T03:58:39.456+00:00There's just that small compilation problem......There's just that small compilation problem...<br /><br />Actually that's a problem with first-class special forms, not with fexprs per se. Second-class fexprs (restricted to being statically known, like ordinary macros, and using only statically determinable environments — did I miss any restrictions?) have expressive power equal to macros, and can always be compiled by inlining. I don't know if anyone has tried this yet.<br /><br />FWIW I'm not sure fexprs are really cleaner than macros — they force environments to exist at runtime, while macros are purely static, and wonderfully simple at heart. It's the hygiene and phasing apparatus that's unclean.Arcane Sentimenthttps://www.blogger.com/profile/04144052171693893368noreply@blogger.comtag:blogger.com,1999:blog-6454006.post-33898584407430356102013-09-16T02:19:30.351+00:002013-09-16T02:19:30.351+00:00How about fexprs? To me, they're macros done r...How about fexprs? To me, they're macros done right: hygiene is trivial, phasing problems are non-existent, and the design is just much cleaner. newt0311https://www.blogger.com/profile/00275501056310821335noreply@blogger.comtag:blogger.com,1999:blog-6454006.post-66645168855360871232013-09-16T00:41:13.740+00:002013-09-16T00:41:13.740+00:00One of my beefs with macros (vs builtins) is exact...One of my beefs with macros (vs builtins) is exactly the analysis issue; how do you get good (i.e. semantic) error messages, warnings etc. out of features implemented as macros? IMO the (practical) analysis issue is rather harder for macros than builtins, without a whole lot of other machinery that starts dictating the design of your compiler.<br /><br />But my biggest beef is that they enable above-average programmers to create their own half-baked embedded language. A bunch of people do this for various libraries, and now you have to try and compose the lot of them. Or you have to hire new people to work on code that's effectively written in a proprietary language nobody wants to learn. Highly expressive macros enable too much weirdness, without enough enforcement of conventionality. A situation that's fine when you're working all on your own, but not sustainable in a broader ecosystem.<br /><br />I'm not arguing for Java, by any means, but there's a lot of power in a software ecosystem that has common constructs that everybody uses, such that you don't have to deal with type incompatibilities and write shims to join two libraries together. And a limited language defines the scope of a library's interface. But macros enable arbitrary enhancement of the language, and you'll end up with different groups creating different, incompatible implementations of common ideas, and a mess trying to glue them all together.Barry Kellyhttps://www.blogger.com/profile/10559947643606684495noreply@blogger.com