And a simple example of what the code might look like when using it: https://gist.github.com/anonymous/790a690597069fe70b8c874a042d52d0
On Tue, Sep 20, 2016 at 6:47 PM, Jens Persson <[email protected]> wrote: > Here's the code for the little meta-programming tool, SwiftInSwift: > https://gist.github.com/anonymous/07d9df1a80820bb5abf5a2c671fd223f > /Jens > > On Tue, Sep 20, 2016 at 6:28 PM, Jens Persson <[email protected]> wrote: > >> You can put DEF-blocks and PRINT-blocks in your code, eg: >> >> // DEF-{ >> func generateSomeCode() -> [String] { >> var linesOfCode = [String]() >> // ... fill linesOfCode with some interesting code ... >> return linesOfCode >> } >> // }-DEF >> >> // PRINT-{ generateSomeCode() >> // The result of the print-block-expression will >> // replace these lines when cmd+B is pressed. >> // }-PRINT >> >> When you press cmd+B, the meta-programming-tool will put together a Swift >> script of the DEF-blocks and PRINT-block-expressions, and evaluate the >> expressions of the PRINT-blocks, which can be any expression that resolve >> into a [String], ie the lines of code which will replace the content of the >> PRINT-block. >> >> /Jens >> >> >> On Tue, Sep 20, 2016 at 4:34 PM, Vladimir.S <[email protected]> wrote: >> >>> On 20.09.2016 16:43, Jens Persson via swift-evolution wrote: >>> >>>> Sure, but the reason to go for C++ in this case would only be to be >>>> able to >>>> use eg its templates and constexprs, things that doesn't translate well >>>> into Swift. And I think it's a long term goal of Swift to become a >>>> systems >>>> language. >>>> >>>> We ended up making a meta-programming-tool that we use as a Build Phase, >>>> before compilation, that lets us write code-generating Swift code, >>>> within >>>> our ordinary Swift code. (A bit like GYB but Swift-only, using just >>>> regular >>>> Swift within our regular Swift source files.) >>>> >>>> This DIY meta programming facility let's us overcome the current >>>> limitations of Swift's type system in a somewhat convenient/nice way. >>>> >>> >>> Very interesting. Could you share some examples of how your source code >>> looks like(this "code-generating Swift code") and what is produced by this >>> "meta-programming-tool" ? >>> >>> >>>> /Jens >>>> >>>> >>>> On Mon, Sep 19, 2016 at 10:07 PM, Goffredo Marocchi <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> If you have to compromise that much, it makes for a very compelling >>>> case to go for C++ wrapped in Objective-C(++) as far as that >>>> section of >>>> the code is concerned and call it from Swift using the already >>>> provided >>>> bridging support. >>>> >>>> I do not think anyone will question the purity of our bodily >>>> fluids/minds if we do not write 100% of code in Swift :), support >>>> for >>>> interoperability with other languages is there for a reason IMHO and >>>> should be expanded and not begrudged. >>>> >>>> Sent from my iPhone >>>> >>>> On 19 Sep 2016, at 14:14, Jens Persson via swift-evolution >>>> <[email protected] <mailto:[email protected]>> >>>> wrote: >>>> >>>> Ok, thanks! I take it that we should not expect any dramatic >>>>> advances >>>>> of Swift's type system any time soon. >>>>> >>>>> Reason for asking is that we are trying to write an API for >>>>> N-dimensional graphics/audio/signal/data processing. >>>>> >>>>> Metal, vDSP, simd, etc. would perhaps be used, but only behind the >>>>> scenes, eventually, as necessary, since we want something more >>>>> uniform and math-like, thus allowing for a more rapid experimental >>>>> style of coding, where you can quickly try something out for a >>>>> different number of dimensions, etc. >>>>> >>>>> This has turned out to be impossibly hard to write in current >>>>> Swift, >>>>> unless you are willing to either >>>>> >>>>> 1. Forget about performance and type safety, ie use a standard >>>>> Array >>>>> (instead of a static vector with type-level Count as well as >>>>> Element) >>>>> for N-dimensional positions, matrices, vectors, indices, etc. >>>>> >>>>> 2. Forget about code reuse / abstractions. >>>>> >>>>> Option 1 is not an alternative. We want to let the compiler (and >>>>> our >>>>> code) know/optimize as much as possible, otherwise it will be >>>>> unusably slow even for ("rapid") prototyping. >>>>> >>>>> So we'll probably go with option 2 and spell out / generate code >>>>> for >>>>> each and every permutation of >>>>> (dim, data-structure, function/algorithm), and sadly this will also >>>>> be necessary for every piece of code that uses the API, since it is >>>>> impossible to write eg >>>>> >>>>> A generic StaticVector type with type parameters for its Count and >>>>> Element. >>>>> >>>>> A generic N-dimensional array type with type parameters for its >>>>> (NDim)Index: StaticVector (where Index.Element == Int) >>>>> and >>>>> Element >>>>> >>>>> Or we'll have to use (Obj) C++ : / >>>>> >>>>> /Jens >>>>> >>>>> >>>>> >>>>> On Mon, Sep 19, 2016 at 3:22 AM, Robert Widmann >>>>> <[email protected] <mailto:[email protected]>> >>>>> wrote: >>>>> >>>>> >>>>> On Sep 17, 2016, at 6:37 PM, Jens Persson via swift-evolution >>>>>> <[email protected] <mailto:[email protected] >>>>>> >> >>>>>> >>>>>> wrote: >>>>>> >>>>>> Has there been any discussions about the possibility of having >>>>>> generic associatedtypes? >>>>>> >>>>>> I (naively) think that it would open up a lot of >>>>>> possibilities. >>>>>> Because if, for example, we could do this: >>>>>> >>>>>> protocol CountType { >>>>>> associatedtype Storage<E> >>>>>> ... >>>>>> } >>>>>> >>>>>> Then we could do this: >>>>>> >>>>>> struct Count1 : CountType { >>>>>> typealias Storage<E> = (E) >>>>>> ... >>>>>> } >>>>>> struct Count2 : CountType { >>>>>> typealias Storage<E> = (E, E) >>>>>> ... >>>>>> } >>>>>> struct Count3 : CountType { >>>>>> typealias Storage<E> = (E, E, E) >>>>>> ... >>>>>> } >>>>>> ... >>>>>> protocol StaticArrayType { >>>>>> associatedtype Count: CountType >>>>>> associatedtype Element >>>>>> ... >>>>>> } >>>>>> struct StaticArray<C: CountType, Element> : StaticArrayType { >>>>>> typealias Count = C >>>>>> var storage: C.Storage<Element> >>>>>> ... >>>>>> } >>>>>> >>>>>> >>>>>> >>>>>> Would adding support for generic associatedtypes be possible? >>>>>> Are there any plans for it? >>>>>> >>>>> >>>>> Possible, yes, plans, no. >>>>> >>>>> Generic associated types go part and parcel with higher-kinded >>>>> quantification and higher-kinded types, the implementation >>>>> challenges of which have been discussed thoroughly on this list >>>>> and elsewhere. Is there a particular flavor you had in mind? >>>>> >>>>> One major problem is that presumably you’d want to constrain >>>>> such >>>>> a generic associatedtype and then we’d have to have some kind >>>>> of >>>>> type-level-yet-runtime-relevant apply of a generic witness >>>>> table >>>>> to another potentially generic witness. It’s not clear what >>>>> that >>>>> kind of thing would look like, or how far it would have to be >>>>> taken to get the kind of support you would expect from a basic >>>>> implementation higher associatedtypes. Implementations in >>>>> languages like Haskell tend to also be horrendously >>>>> inefficient - >>>>> I believe Edward Kmett calls is the “Mother May I” effect of >>>>> forcing a witness table to indirect through multiple layers of >>>>> the witness because inlining necessarily fails for the majority >>>>> of these things in the MTL. >>>>> >>>>> tl;dr Basic examples like the ones you cite hide the kinds of >>>>> tremendously evil fun things you can do once you have these >>>>> kinds >>>>> of features. >>>>> >>>>> >>>>>> ( >>>>>> I tried searching for it but I found only this: >>>>>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mo >>>>>> n-20160411/015089.html >>>>>> <https://lists.swift.org/pipermail/swift-evolution/Week-of-M >>>>>> on-20160411/015089.html> >>>>>> ) >>>>>> >>>>>> Thanks, >>>>>> /Jens >>>>>> >>>>>> _______________________________________________ >>>>>> swift-evolution mailing list >>>>>> [email protected] <mailto:[email protected]> >>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> swift-evolution mailing list >>>>> [email protected] <mailto:[email protected]> >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> [email protected] >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> >>>> >> >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
