[swift-evolution] generic associatedtype?

Jens Persson jens at bitcycle.com
Tue Sep 20 12:04:51 CDT 2016


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 <jens at bitcycle.com> 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 <jens at bitcycle.com> 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 <svabox at gmail.com> 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 <panajev at gmail.com
>>>> <mailto:panajev at gmail.com>> 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
>>>>     <swift-evolution at swift.org <mailto:swift-evolution at swift.org>>
>>>> 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
>>>>>     <devteam.codafi at gmail.com <mailto:devteam.codafi at gmail.com>>
>>>>> wrote:
>>>>>
>>>>>
>>>>>         On Sep 17, 2016, at 6:37 PM, Jens Persson via swift-evolution
>>>>>>         <swift-evolution at swift.org <mailto:swift-evolution at swift.org
>>>>>> >>
>>>>>>
>>>>>>         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
>>>>>>         swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>>>>         https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>>>         <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>>>>
>>>>>
>>>>>
>>>>>     _______________________________________________
>>>>>     swift-evolution mailing list
>>>>>     swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>>>     https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>>     <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>
>>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160920/d0a3088c/attachment.html>


More information about the swift-evolution mailing list