[swift-evolution] generic associatedtype?
Jens Persson
jens at bitcycle.com
Tue Sep 20 11:28:17 CDT 2016
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-
>>>> Mon-20160411/015089.html
>>>> <https://lists.swift.org/pipermail/swift-evolution/Week-of-
>>>> Mon-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/b2bded2a/attachment.html>
More information about the swift-evolution
mailing list