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<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?

(
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

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.

···

On Sep 17, 2016, at 6:37 PM, Jens Persson via swift-evolution <swift-evolution@swift.org> wrote:

(
I tried searching for it but I found only this:
[swift-evolution] [Discussion] Dictionary Key as Index
)

Thanks,
/Jens

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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@gmail.com> 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<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:
The swift-evolution Archives
Week-of-Mon-20160411/015089.html
)

Thanks,
/Jens

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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 <devteam.codafi@gmail.com> 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<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:
[swift-evolution] [Discussion] Dictionary Key as Index
)

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

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 <panajev@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@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@gmail.com> > 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<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
)

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

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" ?

···

On 20.09.2016 16:43, Jens Persson via swift-evolution wrote:

/Jens

On Mon, Sep 19, 2016 at 10:07 PM, Goffredo Marocchi <panajev@gmail.com > <mailto:panajev@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@swift.org <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 >> <devteam.codafi@gmail.com <mailto:devteam.codafi@gmail.com>> wrote:

        On Sep 17, 2016, at 6:37 PM, Jens Persson via swift-evolution >>> <swift-evolution@swift.org <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<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:
        [swift-evolution] [Discussion] Dictionary Key as Index
        <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160411/015089.html&gt;
        )

        Thanks,
        /Jens

        _______________________________________________
        swift-evolution mailing list
        swift-evolution@swift.org <mailto:swift-evolution@swift.org>
        https://lists.swift.org/mailman/listinfo/swift-evolution
        <https://lists.swift.org/mailman/listinfo/swift-evolution&gt;

    _______________________________________________
    swift-evolution mailing list
    swift-evolution@swift.org <mailto:swift-evolution@swift.org>
    https://lists.swift.org/mailman/listinfo/swift-evolution
    <https://lists.swift.org/mailman/listinfo/swift-evolution&gt;

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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@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@gmail.com >> <mailto:panajev@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@swift.org <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 >>> <devteam.codafi@gmail.com <mailto:devteam.codafi@gmail.com>> wrote:

        On Sep 17, 2016, at 6:37 PM, Jens Persson via swift-evolution >>>> <swift-evolution@swift.org <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<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@swift.org <mailto:swift-evolution@swift.org>
        https://lists.swift.org/mailman/listinfo/swift-evolution
        <https://lists.swift.org/mailman/listinfo/swift-evolution&gt;

    _______________________________________________
    swift-evolution mailing list
    swift-evolution@swift.org <mailto:swift-evolution@swift.org>
    https://lists.swift.org/mailman/listinfo/swift-evolution
    <https://lists.swift.org/mailman/listinfo/swift-evolution&gt;

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Here's the code for the little meta-programming tool, SwiftInSwift:

/Jens

···

On Tue, Sep 20, 2016 at 6:28 PM, Jens Persson <jens@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@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@gmail.com >>> <mailto:panajev@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@swift.org <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 >>>> <devteam.codafi@gmail.com <mailto:devteam.codafi@gmail.com>> wrote:

        On Sep 17, 2016, at 6:37 PM, Jens Persson via swift-evolution >>>>> <swift-evolution@swift.org <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<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@swift.org <mailto:swift-evolution@swift.org>
        https://lists.swift.org/mailman/listinfo/swift-evolution
        <https://lists.swift.org/mailman/listinfo/swift-evolution&gt;

    _______________________________________________
    swift-evolution mailing list
    swift-evolution@swift.org <mailto:swift-evolution@swift.org>
    https://lists.swift.org/mailman/listinfo/swift-evolution
    <https://lists.swift.org/mailman/listinfo/swift-evolution&gt;

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

And a simple example of what the code might look like when using it:

···

On Tue, Sep 20, 2016 at 6:47 PM, Jens Persson <jens@bitcycle.com> wrote:

Here's the code for the little meta-programming tool, SwiftInSwift:
SwiftInSwift - A poor man's meta programming tool for Swift · GitHub
/Jens

On Tue, Sep 20, 2016 at 6:28 PM, Jens Persson <jens@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@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@gmail.com >>>> <mailto:panajev@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@swift.org <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 >>>>> <devteam.codafi@gmail.com <mailto:devteam.codafi@gmail.com>> >>>>> wrote:

        On Sep 17, 2016, at 6:37 PM, Jens Persson via swift-evolution >>>>>> <swift-evolution@swift.org <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<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@swift.org <mailto:swift-evolution@swift.org>
        https://lists.swift.org/mailman/listinfo/swift-evolution
        <https://lists.swift.org/mailman/listinfo/swift-evolution&gt;

    _______________________________________________
    swift-evolution mailing list
    swift-evolution@swift.org <mailto:swift-evolution@swift.org>
    https://lists.swift.org/mailman/listinfo/swift-evolution
    <https://lists.swift.org/mailman/listinfo/swift-evolution&gt;

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution