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.
> On Jul 30, 2017, at 8:54 PM, Christopher Kornher <ckorn...@me.com> 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 >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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 <2...@gmx.de <mailto:2...@gmx.de>> >>> 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 >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
