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 <sva...@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 <pana...@gmail.com
>> <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
>>     <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.cod...@gmail.com <mailto:devteam.cod...@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>
>>>>
>>>
>>>
>>>     _______________________________________________
>>>     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>
>>>
>>
>>
>>
>>
>> _______________________________________________
>> 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

Reply via email to