For completeness: I forgot to mention that I have been meaning to check-out Sourcery, which is possibly a more “Swifty” tool. I use Cog’s file-scope extensively, and it is unclear to me if that is a feature of Sourcery
https://github.com/krzysztofzablocki/Sourcery OK, now I am sure that someone is going to tell me that I am off-topic :) - Chris K > On Jul 30, 2017, at 11:54 AM, Christopher Kornher <[email protected]> wrote: > > 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, . > > 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. > > 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. > > 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. > > 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. > > See Cog: > https://nedbatchelder.com/code/cog/ <https://nedbatchelder.com/code/cog/> > > 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. > > 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. > > - Chris > > >> On Jul 30, 2017, at 11:03 AM, Gor Gyolchanyan via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >> Tino Heth: >> 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 compiletime >> beautifully 🙂. >> Now what I really want at this point is to here the opinions of the core >> team on this topic. >> >> Swift Core Team: >> 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? >> >>> On Jul 30, 2017, at 7:56 PM, Tino Heth <[email protected] <mailto:[email protected]>> >>> wrote: >>> >>> >>>> more elaborate compile-time facilities, which would also provide extremely >>>> powerful meta programming features >>> 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… ;-) >>> I took a brief look at the C++ document, but it seemed still to much >>> macro-like to me. >>> >>> My take on the topic would be he ability to express common programming >>> tasks (declaring a class, overriding a method…) in the language itself. >>> Imagine >>> public class ProxyViewController: UIView {} >>> Could be written as >>> let subclass = createClass(classname: "ProxyViewController", superclass: >>> UIViewController, accessLevel: .public) >>> >>> 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" ;-). >>> But now imagine that: >>> >>> for (method, implementation) in UIViewController.methods where >>> method.accessLevel == .open { >>> subclass.methods[method] = { parameters in >>> print("Subclass method \(method) called with \(parameters)") >>> return implementation(parameters) >>> } >>> } >>> >>> >>> Not that stupid anymore, isn't it? >>> I think this would be way cooler than poking around with variants of search >>> & replace… >>> >>> - Tino >>> >>> (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 ;-) >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
