<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">On Jul 30, 2017, at 9:29 PM, Christopher Kornher <<a href="mailto:ckornher@me.com" class="">ckornher@me.com</a>> wrote:</div></blockquote><blockquote type="cite" class=""><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">I am not sure that macros and annotations would be good, either. It may be impossible to avoid them, given Swift’s goal of “world domination”. Both features are very useful in certain applications.</div></div></div></blockquote><div><br class=""></div>I’d argue that exposing swift’s front-end as a built-in module with APIs for creating instances of language constructs and building them programmatically and then allowing one to run that code at compile time would make it much easier to achieve “world domination” because generating code through a well-defined and well-documented API written in the same language as the one being generated would be much easier than using the equivalent of what Xcode uses to represent the code for semantical highlighting, navigation and debugging purposes (which, I imagine, is just text with some metadata).<br class=""><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">We could continue to use custom tools like Cog and Sourcery when we need to, or standardize and better integrate their functionality. I honestly am not sure which is a better solution.</div></div></div></blockquote><br class=""><div>Well, gyb is the tool written specifically for swift and a large portion of the standard library and the `Builtin` module is generated by gyb. That doesn’t look like a design choice to me. It looks more like the lesser of two evils (the other being manual, error-prone boilerplate).</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">"Hygienic Macros” and “Annotations” have both been discussed. Both of these features would bring power and complexity to the language, to be sure. I just wanted to voice my opinion that these features, if and when they arrive, should be transparent, i.e., the generated code should be visible and sensibly formatted so that it can be examined and debugged. This would be a hard problem, and I am not sure if it is even possible for complex macro & annotation combinations…</div></div></div></blockquote><div><br class=""></div><div>If the metaprogramming facilities are implemented as a builtin module that exposes the swift frontend as a compile-time API, it would be much easier to adapt the debugging tools to encompass it, than trying to reverse-engineer the code, generated by semantically-unaware macro system, since the generated code was never in textual form in the first place. It would even allow things like Xcode generating a textural representation of the generated source for debugging purposes (where your mentioned formatters would come in handy).</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">C macros are not hygienic and not “transparent”. C preprocessor output, for example, is largely unusable.</div><div class=""><br class=""></div><div class="">The uses of macros and annotation overlap. Introducing macros and annotations at the same time would provide a chance to sensibly balance the features of each and provide a coherent set of guidelines for developers. </div></div></div></blockquote><div><br class=""></div><div>I’m not sure what you mean by “annotations”, but if you’re referring to arbitrary user-defined metadata attached to language constructs, then the API-based codeine would make this exceedingly easy, because LLVM libraries natively support metadata on pretty much everything, so it would be a simple matter of not forgetting to expose those to Swift as well.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">- Chris K</div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jul 30, 2017, at 12:03 PM, Gor Gyolchanyan via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">I don’t think a Cog-like or Gyb-like macro system would be good. That’s essentially a preprocessor and we all know how that worked out for C. The only a code-generation feature can exist in a safe language like Swift is by making it a first-class citizen as described previously. I’m not sure whether or not the core team would consider such a thing, bit I am very certain that a text-based macro system is something they’d never consider.</div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jul 30, 2017, at 8:54 PM, Christopher Kornher <<a href="mailto:ckornher@me.com" class="">ckornher@me.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">I assume that the planned “hygienic macro” facility, if it has access to metadata, or “annotations", could be used for these sorts of meta tasks, .</div><div class=""><br class=""></div><div class="">This is slightly off-topic, but I hope that there is a way for macros to be fully expanded and debuggable (and even formatted). I use Cog with Swift as a kind of "macro-system on steroids” that provides these features. I would love to see a Cog-like system included as a standard feature of the language in the future. It could be a component of annotations, macros, or both.</div><div class=""><br class=""></div><div class="">I would like to see a source code generation pre-pass added for annotations, and hopefully macros when they arrive, so that developers can see, debug, and code against the expanded code. I realize that may be difficult or even impossible for some macros.</div><div class=""><br class=""></div><div class="">GOG uses Python as its macro language, which is certainly compatible with Apple’s toolchain. Using a real programming language for annotations, is extremely powerful.</div><div class=""><br class=""></div><div class="">The danger of adding a macro system too early, is that it can be used as a “cheat” to implement functionality that should be part of the base language and discourage language development. I trust that the core team will not let this happen.</div><div class=""><br class=""></div><div class="">See Cog: </div><div class=""><a href="https://nedbatchelder.com/code/cog/" class="">https://nedbatchelder.com/code/cog/</a></div><div class=""><br class=""></div><div class="">A fully integrated Cog-like facility this should have language support to cleanup the (pretty ugly) delimiters and eventually tool support to selectively toggle expansion, as we can today with code blocks, for example, in many tools.</div><div class=""><br class=""></div><div class="">I don’t mean to derail this discussion, but it seems that an annotation or macro system would be appropriate for this kind of feature.</div><div class=""><br class=""></div><div class="">- Chris</div><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jul 30, 2017, at 11:03 AM, Gor Gyolchanyan via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Tino Heth:</div>If you read my reply to Daniel Vollmer, you’ll find that we’re thinking about the exact same thing. Your code snippers show my vision of <font color="#941751" face="Menlo" class="">compiletime</font> beautifully 🙂.<div class="">Now what I really want at this point is to here the opinions of the core team on this topic.</div><div class=""><br class=""></div><div class="">Swift Core Team:</div><div class="">Have you guys thought of this? Do you think this is a good idea to put on the table or do you have different plans?</div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jul 30, 2017, at 7:56 PM, Tino Heth <<a href="mailto:2th@gmx.de" class="">2th@gmx.de</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">more elaborate compile-time facilities, which would also provide extremely powerful meta programming features</span></div></blockquote></div>That's an interesting twist — but whenever you put a "meta" somewhere, things tend to get complicated, and people end up with different associations to the topic… ;-)<div class="">I took a brief look at the C++ document, but it seemed still to much macro-like to me.</div><div class=""><br class=""></div><div class="">My take on the topic would be he ability to express common programming tasks (declaring a class, overriding a method…) in the language itself.</div><div class="">Imagine</div><div class=""><div class=""><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><span style="font-variant-ligatures: no-common-ligatures; color: rgb(186, 45, 162);" class="">public</span><span style="font-variant-ligatures: no-common-ligatures;" class=""> </span><span style="font-variant-ligatures: no-common-ligatures; color: rgb(186, 45, 162);" class="">class</span><span style="font-variant-ligatures: no-common-ligatures;" class=""> ProxyViewController: </span><span style="font-variant-ligatures: no-common-ligatures; color: rgb(112, 61, 170);" class="">UIView</span><span style="font-variant-ligatures: no-common-ligatures;" class=""> {}</span></div></div></div><div class="">Could be written as</div><div class=""><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><span style="font-variant-ligatures: no-common-ligatures; color: #ba2da2" class="">let</span><span style="font-variant-ligatures: no-common-ligatures" class=""> subclass = </span><span style="font-variant-ligatures: no-common-ligatures; color: #31595d" class="">createClass</span><span style="font-variant-ligatures: no-common-ligatures" class="">(classname: </span><span style="font-variant-ligatures: no-common-ligatures; color: #d12f1b" class="">"ProxyViewController"</span><span style="font-variant-ligatures: no-common-ligatures" class="">, superclass: </span><span style="font-variant-ligatures: no-common-ligatures; color: #4f8187" class="">UIViewController</span><span style="font-variant-ligatures: no-common-ligatures" class="">, accessLevel: .</span><span style="font-variant-ligatures: no-common-ligatures; color: #31595d" class="">public</span><span style="font-variant-ligatures: no-common-ligatures" class="">)</span></div></div><div class=""><br class=""></div><div class="">Quite stupid at first sight, and basically the exact opposite of syntactic sugar ("syntactic salt" already has a meaning… so I'd call it "syntactic pepper" ;-).</div><div class="">But now imagine that:</div><div class=""><br class=""></div><div class=""><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><div style="margin: 0px; line-height: normal;" class=""><span style="font-variant-ligatures: no-common-ligatures; color: #ba2da2" class="">for</span><span style="font-variant-ligatures: no-common-ligatures" class=""> (method, implementation) </span><span style="font-variant-ligatures: no-common-ligatures; color: #ba2da2" class="">in</span><span style="font-variant-ligatures: no-common-ligatures" class=""> </span><span style="font-variant-ligatures: no-common-ligatures; color: #4f8187" class="">UIViewController</span><span style="font-variant-ligatures: no-common-ligatures" class="">.</span><span style="font-variant-ligatures: no-common-ligatures; color: #4f8187" class="">methods</span><span style="font-variant-ligatures: no-common-ligatures" class=""> </span><span style="font-variant-ligatures: no-common-ligatures; color: #ba2da2" class="">where</span><span style="font-variant-ligatures: no-common-ligatures" class=""> method.</span><span style="font-variant-ligatures: no-common-ligatures; color: #4f8187" class="">accessLevel</span><span style="font-variant-ligatures: no-common-ligatures" class=""> </span><span style="font-variant-ligatures: no-common-ligatures; color: #31595d" class="">==</span><span style="font-variant-ligatures: no-common-ligatures" class=""> .</span><span style="font-variant-ligatures: no-common-ligatures; color: #31595d" class="">open</span><span style="font-variant-ligatures: no-common-ligatures" class=""> {</span></div><div style="margin: 0px; line-height: normal;" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""> </span><span style="font-variant-ligatures: no-common-ligatures; color: #4f8187" class="">subclass</span><span style="font-variant-ligatures: no-common-ligatures" class="">.</span><span style="font-variant-ligatures: no-common-ligatures; color: #4f8187" class="">methods</span><span style="font-variant-ligatures: no-common-ligatures" class="">[method] = { parameters </span><span style="font-variant-ligatures: no-common-ligatures; color: #ba2da2" class="">in</span></div><div style="margin: 0px; line-height: normal; color: rgb(209, 47, 27);" class=""><span style="font-variant-ligatures: no-common-ligatures;" class=""> </span><span style="font-variant-ligatures: no-common-ligatures; color: #3e1e81" class="">print</span><span style="font-variant-ligatures: no-common-ligatures;" class="">(</span><span style="font-variant-ligatures: no-common-ligatures" class="">"Subclass method </span><span style="font-variant-ligatures: no-common-ligatures;" class="">\</span><span style="font-variant-ligatures: no-common-ligatures" class="">(</span><span style="font-variant-ligatures: no-common-ligatures;" class="">method</span><span style="font-variant-ligatures: no-common-ligatures" class="">) called with </span><span style="font-variant-ligatures: no-common-ligatures;" class="">\</span><span style="font-variant-ligatures: no-common-ligatures" class="">(</span><span style="font-variant-ligatures: no-common-ligatures;" class="">parameters</span><span style="font-variant-ligatures: no-common-ligatures" class="">)"</span><span style="font-variant-ligatures: no-common-ligatures;" class="">)</span></div><div style="margin: 0px; line-height: normal;" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""> </span><span style="font-variant-ligatures: no-common-ligatures; color: #ba2da2" class="">return</span><span style="font-variant-ligatures: no-common-ligatures" class=""> implementation(parameters)</span></div><div style="margin: 0px; line-height: normal;" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""> }</span></div><div style="margin: 0px; line-height: normal;" class=""><span style="font-variant-ligatures: no-common-ligatures" class="">}</span></div><div class=""><span style="font-variant-ligatures: no-common-ligatures" class=""><br class=""></span></div></div></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""><br class=""></span></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><span style="font-family: Helvetica; font-size: 12px;" class="">Not that stupid anymore, isn't it?</span></div><div style="margin: 0px; line-height: normal;" class=""><span style="font-family: Helvetica; font-size: 12px;" class="">I think this would be way cooler than poking around with variants of search & replace</span>…</div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><span style="font-family: Helvetica; font-size: 12px;" class=""><br class=""></span></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><span style="font-family: Helvetica; font-size: 12px;" class="">- Tino</span></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><span style="font-family: Helvetica; font-size: 12px;" class=""><br class=""></span></div><div style="margin: 0px; line-height: normal;" class="">(to get syntax colouring, I wrote ~30 lines of Swift that turn the straw man example into valid code… it's fun, maybe I play with it a little bit more ;-)</div></div></div></blockquote></div><br class=""></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></body></html>