Proposal: Go2: add hygienic macros

[beoran]

In #32437, a proposal is made for error handing based on a built-in function. However all that is proposed is in essence, much like append(), simply a special case macro for code that can be implemented in Go manually.

One problem I often encounter in Go is that there quite a bit of boilerplate to implement certain functionality, not only in error handling, but in general. Generics have been proposed as a solution to this, but, as can be seen from the proposal I mentioned before, if ever implemented, will be unlikely to be powerful enough to allow the go programmer to implement such error handling boilerplate themselves.

Also we have go:generate, which I use often to generate go code from text/template, but is not part of the language itself, and allows me to use all sorts of C-like preprocessors agnd generators that use text/template go code, with all the downsides of this kind of preprocessors and generators.

Therefore I propose that Go would be enhanced with hygienic macros. They would have to be powerful enough to functions such as try() and append() to be implementable in the Go language itself. They would then also allow to reduce boilerplate many other cases as well. Probably they would have to be based on AST rewriting much like hygienic macros in other languages.

I don't even want to start discussing syntax, but perhaps something like https://github.com/cosmos72/gomacro would be a starting point.

I opened this issue to see if others and the Go designers feel this idea could be useful and acceptable. It seems a better idea to me to introduce a more generally useful hygienic macro feature in Go, than, like has been done before, introduce one off macros for particular cases only. Hygienic macros are a well known feature of many programming languages, for which efficient implementation algorithms exist, which might be more useful than generics to reduce boilerplate in Go considerably, and which can be taught and explained relatively easily. So I think they would have many benefits that would outweigh the cost of implementing them.

Edit: link for more details:

https://en.wikipedia.org/wiki/Hygienic_macro

[networkimprov]

At least one of these links is a general purpose macro system
https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback#inlining

@gopherbot add Go2, LanguageChange

[beoran]

Yes, this ... https://medium.com/@phlatphrog/handling-more-than-just-errors-in-go-f97c5aa2eac4 ... Looks like it could fit the ticket, with some refinement. Thanks for the suggestion. Op vr 14 jun. 2019 17:07 schreef Liam <notifications@github.com>:

…

At least one of these links is a general purpose macro system https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback#inlining @gopherbot <https://github.com/gopherbot> add Go2, LanguageChange — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#32620?email_source=notifications&email_token=AAARM6OKHW5VLDN7ZZCD4O3P2OX4BA5CNFSM4HYHEYT2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXXB4ZQ#issuecomment-502144614>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAARM6MNC3IHQMVF2QR3OWDP2OX4BANCNFSM4HYHEYTQ> .

[ianlancetaylor]

If the try builtin proposal can be implemented as a macro, then macros can change control flow. That does not strike me as a good feature. A number of people have reasonably objected to try on the grounds that it changes control flow, and therefore makes the program harder to understand. If macros can change control flow, then macros can similarly make a program harder to understand. Much harder. That seems like a problem.

[urandom]

@ianlancetaylor
catch from the draft proposal can also change control flow. There's nothing inherently wrong with that, and as with other language constructs that do the same, I assume people will either learn how they work or not use them.

[beoran]

@ianlancetaylor
Personally I don't think the problem with try is that it changes flow control. Actually, to be useful and save on boilerplate, it should do so. The problem is that we can't implement such flow control changing try, cond, etc, macros ourselves, and customize them to our own liking.

And if flow control changing special case built in macros like try are desirable to reduce boilerplate, then moreso can be said for programmer defined macros, when used judiciously like @urandom suggests. The Go standard library could contain a few standard macros that are well documented and of common use, such as try.

If you read the link to phlatprog's medium you will see how he suggests a macro similar to try could be implemented. He suggests that a macro is like a func, but the body of the macro is inserted hygienically inline in the macro call site with the parameters substituted in the body. I really like this idea, because it is simple to explain, but extremely useful.

[iand]

Rust implements it's try feature as a macro: https://doc.rust-lang.org/1.9.0/std/macro.try!.html

[deanveloper]

I personally agree with @ianlancetaylor's sentiment here. Maybe if we had a distinction between macros and functions (such as rust's try! and println!), this would seem a bit better. Then we can at least clearly see where control flow may be happening.

[beoran]

Well, why not? I didn't propose any syntax yet, but maybe some marker like ! or so could be nice. Good to see that try can be implemented as a macro in a language that has hygienic macros. I'd say that this demonstrates the advantages of this idea.

…

[ianlancetaylor]

I think the advantages of hygienic macros are fairly clear.

What I'm personally concerned about is the disadvantages. In particular, it seems to me that it can easily become much harder to read Go code written by somebody else using a different set of macros. I'm concerned that it could become much harder to share Go code, not in the sense that the shared code doesn't run, but in the sense that it is hard to understand and debug the code you didn't write.

[urandom]

I think the advantages of hygienic macros are fairly clear.

What I'm personally concerned about is the disadvantages. In particular, it seems to me that it can easily become much harder to read Go code written by somebody else using a different set of macros. I'm concerned that it could become much harder to share Go code, not in the sense that the shared code doesn't run, but in the sense that it is hard to understand and debug the code you didn't write.

Is there any such precedent in languages with hygienic macros? Granted, that might be hard to observe, but it could be a nice use-case nonetheless.