[swift-evolution] generic associatedtype?
Jens Persson
jens at bitcycle.com
Tue Sep 20 11:47:13 CDT 2016
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/7d1073d9/attachment.html>
More information about the swift-evolution
mailing list