Re: [swift-evolution] generic associatedtype?
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 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 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 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 >>> > 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
mailto:swift-evolution@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++ : /
>
>
Re: [swift-evolution] generic associatedtype?
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 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 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 >> > 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
>>> mailto:swift-evolution@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
mailto:devteam.cod...@gmail.com>> wrote:
On Sep 17, 2016, at 6:37 PM, Jens Persson via swift-evolution
> mailto:swift-evolution@swift.org>>
>
> wrote:
>
> Has there been any discussions about the possibil
Re: [swift-evolution] generic associatedtype?
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 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 > > 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
>> mailto:swift-evolution@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
>>> mailto:devteam.cod...@gmail.com>> wrote:
>>>
>>>
>>> On Sep 17, 2016, at 6:37 PM, Jens Persson via swift-evolution
mailto:swift-evolution@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
...
}
Then we could do this:
Re: [swift-evolution] generic associatedtype?
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 mailto:pana...@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
mailto:swift-evolution@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
mailto:devteam.cod...@gmail.com>> wrote:
On Sep 17, 2016, at 6:37 PM, Jens Persson via swift-evolution
mailto:swift-evolution@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
...
}
Then we could do this:
struct Count1 : CountType {
typealias Storage = (E)
...
}
struct Count2 : CountType {
typealias Storage = (E, E)
...
}
struct Count3 : CountType {
typealias Storage = (E, E, E)
...
}
...
protocol StaticArrayType {
associatedtype Count: CountType
associatedtype Element
...
}
struct StaticArray : StaticArrayType {
typealias Count = C
var storage: C.Storage
...
}
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 ass
Re: [swift-evolution] generic associatedtype?
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.
/Jens
On Mon, Sep 19, 2016 at 10:07 PM, Goffredo Marocchi
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@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
> wrote:
>
>>
>> On Sep 17, 2016, at 6:37 PM, Jens Persson via swift-evolution <
>> swift-evolution@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
>> ...
>> }
>>
>> Then we could do this:
>>
>> struct Count1 : CountType {
>> typealias Storage = (E)
>> ...
>> }
>> struct Count2 : CountType {
>> typealias Storage = (E, E)
>> ...
>> }
>> struct Count3 : CountType {
>> typealias Storage = (E, E, E)
>> ...
>> }
>> ...
>> protocol StaticArrayType {
>> associatedtype Count: CountType
>> associatedtype Element
>> ...
>> }
>> struct StaticArray : StaticArrayType {
>> typealias Count = C
>> var storage: C.Storage
>> ...
>> }
>>
>>
>>
>> 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
Re: [swift-evolution] generic associatedtype?
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
> 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
>> wrote:
>>
>>> On Sep 17, 2016, at 6:37 PM, Jens Persson via swift-evolution
>>> 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
>>> ...
>>> }
>>>
>>> Then we could do this:
>>>
>>> struct Count1 : CountType {
>>> typealias Storage = (E)
>>> ...
>>> }
>>> struct Count2 : CountType {
>>> typealias Storage = (E, E)
>>> ...
>>> }
>>> struct Count3 : CountType {
>>> typealias Storage = (E, E, E)
>>> ...
>>> }
>>> ...
>>> protocol StaticArrayType {
>>> associatedtype Count: CountType
>>> associatedtype Element
>>> ...
>>> }
>>> struct StaticArray : StaticArrayType {
>>> typealias Count = C
>>> var storage: C.Storage
>>> ...
>>> }
>>>
>>>
>>>
>>> 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
>>> )
>>>
>>> Thanks,
>>> /Jens
>>>
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
> ___
> swift-evolut
Re: [swift-evolution] generic associatedtype?
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
wrote:
>
> On Sep 17, 2016, at 6:37 PM, Jens Persson via swift-evolution <
> swift-evolution@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
> ...
> }
>
> Then we could do this:
>
> struct Count1 : CountType {
> typealias Storage = (E)
> ...
> }
> struct Count2 : CountType {
> typealias Storage = (E, E)
> ...
> }
> struct Count3 : CountType {
> typealias Storage = (E, E, E)
> ...
> }
> ...
> protocol StaticArrayType {
> associatedtype Count: CountType
> associatedtype Element
> ...
> }
> struct StaticArray : StaticArrayType {
> typealias Count = C
> var storage: C.Storage
> ...
> }
>
>
>
> 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
> )
>
> Thanks,
> /Jens
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] generic associatedtype?
> On Sep 17, 2016, at 6:37 PM, Jens Persson via swift-evolution
> 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
> ...
> }
>
> Then we could do this:
>
> struct Count1 : CountType {
> typealias Storage = (E)
> ...
> }
> struct Count2 : CountType {
> typealias Storage = (E, E)
> ...
> }
> struct Count3 : CountType {
> typealias Storage = (E, E, E)
> ...
> }
> ...
> protocol StaticArrayType {
> associatedtype Count: CountType
> associatedtype Element
> ...
> }
> struct StaticArray : StaticArrayType {
> typealias Count = C
> var storage: C.Storage
> ...
> }
>
>
>
> 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
>
>
> )
>
> Thanks,
> /Jens
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
[swift-evolution] generic associatedtype?
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
...
}
Then we could do this:
struct Count1 : CountType {
typealias Storage = (E)
...
}
struct Count2 : CountType {
typealias Storage = (E, E)
...
}
struct Count3 : CountType {
typealias Storage = (E, E, E)
...
}
...
protocol StaticArrayType {
associatedtype Count: CountType
associatedtype Element
...
}
struct StaticArray : StaticArrayType {
typealias Count = C
var storage: C.Storage
...
}
Would adding support for generic associatedtypes be possible? Are there any
plans for it?
(
I tried searching for it but I found only this:
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160411/015089.html
)
Thanks,
/Jens
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
