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