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
