Run Swift code at compile time


(Alejandro Martinez) #1

Hi everyone,

Don't take this mail as an oficial proposal but just as some food for thought, I wanted to talk about this to see what you think about it.

I've been following the list since the "Open Source Day" and I've seen in many instances proposals that could have been solved by a macro system, being just a temporal solution since everything can't be done just now or being a permanent solution if that macro system existed. Some of them may include the thread about "code smells", automatic wrapper synthesis or deriving, or even the topic about forwarding calls automatically to an inner object.

My thinking was how difficult or viable it would be to run Swift code from our programs at compile time. I'm not experienced enough on computer languages to see it. The first time that I saw this was in a video from Jonathan Blow (https://www.youtube.com/watch?v=UTqZNujQOlA) and it looked like a really good idea. It would be much better that force people to learn another language (the macro language) or any other kind of preprocessor, instead you could use all your knowledge but just at compile time. It can also have good usages apart form generating code, but generating data that can be generated and known at compile time. And allow even to improve the usage of the language (maybe DSL) at a library level.

Blow seems like is going one step further and allowing the program to call the compiler as if it was a library and even he talks about allowing it to modify the AST, which is maybe going a little to far away.

Anyway, that's the idea. Obviously is not something to be done in the near future.

And sorry if it doesn't make any sense and I'm just making you lose your time.

Cheers,

Alejandro Martínez
@alexito4
http://alejandromp.com


Compile-Time Constant Expressions for Swift
Compile time support for Aspect-oriented programming
(Chris Lattner) #2

This is something that could be very interesting! Unfortunately it is definitely out of scope for Swift 3.

-Chris

···

On Dec 8, 2015, at 12:01 PM, Alejandro Martinez via swift-evolution <swift-evolution@swift.org> wrote:

Hi everyone,

Don't take this mail as an oficial proposal but just as some food for thought, I wanted to talk about this to see what you think about it.

I've been following the list since the "Open Source Day" and I've seen in many instances proposals that could have been solved by a macro system, being just a temporal solution since everything can't be done just now or being a permanent solution if that macro system existed. Some of them may include the thread about "code smells", automatic wrapper synthesis or deriving, or even the topic about forwarding calls automatically to an inner object.

My thinking was how difficult or viable it would be to run Swift code from our programs at compile time. I'm not experienced enough on computer languages to see it. The first time that I saw this was in a video from Jonathan Blow (https://www.youtube.com/watch?v=UTqZNujQOlA) and it looked like a really good idea. It would be much better that force people to learn another language (the macro language) or any other kind of preprocessor, instead you could use all your knowledge but just at compile time. It can also have good usages apart form generating code, but generating data that can be generated and known at compile time. And allow even to improve the usage of the language (maybe DSL) at a library level.


(Andrew Bennett) #3

I like this idea in principle and I know my colleague at work was wishing
for it yesterday.

C++11 has a constexpr which can be calculated at compile time, it can also
call to other functions which are constexpr.

You can make static assertions that produce a compile-time error.

Another powerful feature of this is that a function's argument or return
type could also be a constexpr. This could allow protocols to be much
stronger and have assertions or type restrictions that are currently only
in documentation. Perhaps generic type constraints could be more expressive
too.

:+1: if it doesn't add much syntax, is safe and unsurprising I'm all for
this.

···

On Wed, Dec 9, 2015 at 7:01 AM, Alejandro Martinez via swift-evolution < swift-evolution@swift.org> wrote:

Hi everyone,

Don't take this mail as an oficial proposal but just as some food for
thought, I wanted to talk about this to see what you think about it.

I've been following the list since the "Open Source Day" and I've seen in
many instances proposals that could have been solved by a macro system,
being just a temporal solution since everything can't be done just now or
being a permanent solution if that macro system existed. Some of them may
include the thread about "code smells", automatic wrapper synthesis or
deriving, or even the topic about forwarding calls automatically to an
inner object.

My thinking was how difficult or viable it would be to run Swift code from
our programs at compile time. I'm not experienced enough on computer
languages to see it. The first time that I saw this was in a video from
Jonathan Blow (https://www.youtube.com/watch?v=UTqZNujQOlA) and it looked
like a really good idea. It would be much better that force people to learn
another language (the macro language) or any other kind of preprocessor,
instead you could use all your knowledge but just at compile time. It can
also have good usages apart form generating code, but generating data that
can be generated and known at compile time. And allow even to improve the
usage of the language (maybe DSL) at a library level.

Blow seems like is going one step further and allowing the program to call
the compiler as if it was a library and even he talks about allowing it to
modify the AST, which is maybe going a little to far away.

Anyway, that's the idea. Obviously is not something to be done in the near
future.

And sorry if it doesn't make any sense and I'm just making you lose your
time.

Cheers,

Alejandro Martínez
@alexito4
http://alejandromp.com

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


(Tyler Cloutier) #4

Woah, Alejandro, thanks for posting this! That talk was super interesting, particularly exciting at 49:48 <https://youtu.be/UTqZNujQOlA?t=49m48s>. That was just plan cool. Jonathan Blow is quite the orthogonal thinker.

+1 for this, or at least to evaluate how it would fit into the language!

Tyler

···

On Dec 8, 2015, at 12:01 PM, Alejandro Martinez via swift-evolution <swift-evolution@swift.org> wrote:

Hi everyone,

Don't take this mail as an oficial proposal but just as some food for thought, I wanted to talk about this to see what you think about it.

I've been following the list since the "Open Source Day" and I've seen in many instances proposals that could have been solved by a macro system, being just a temporal solution since everything can't be done just now or being a permanent solution if that macro system existed. Some of them may include the thread about "code smells", automatic wrapper synthesis or deriving, or even the topic about forwarding calls automatically to an inner object.

My thinking was how difficult or viable it would be to run Swift code from our programs at compile time. I'm not experienced enough on computer languages to see it. The first time that I saw this was in a video from Jonathan Blow (https://www.youtube.com/watch?v=UTqZNujQOlA) and it looked like a really good idea. It would be much better that force people to learn another language (the macro language) or any other kind of preprocessor, instead you could use all your knowledge but just at compile time. It can also have good usages apart form generating code, but generating data that can be generated and known at compile time. And allow even to improve the usage of the language (maybe DSL) at a library level.

Blow seems like is going one step further and allowing the program to call the compiler as if it was a library and even he talks about allowing it to modify the AST, which is maybe going a little to far away.

Anyway, that's the idea. Obviously is not something to be done in the near future.

And sorry if it doesn't make any sense and I'm just making you lose your time.

Cheers,

Alejandro Martínez
@alexito4
http://alejandromp.com

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


(Alejandro Martinez) #5

Yeah definitely nothing for Swift 3, totally understandable.
I was just curious if it was feasible or just a simple NONO.
Thanks for answering!

···

Sent from my iPad

On 09 Dec 2015, at 05:26, Chris Lattner <clattner@apple.com> wrote:

On Dec 8, 2015, at 12:01 PM, Alejandro Martinez via swift-evolution <swift-evolution@swift.org> wrote:

Hi everyone,

Don't take this mail as an oficial proposal but just as some food for thought, I wanted to talk about this to see what you think about it.

I've been following the list since the "Open Source Day" and I've seen in many instances proposals that could have been solved by a macro system, being just a temporal solution since everything can't be done just now or being a permanent solution if that macro system existed. Some of them may include the thread about "code smells", automatic wrapper synthesis or deriving, or even the topic about forwarding calls automatically to an inner object.

My thinking was how difficult or viable it would be to run Swift code from our programs at compile time. I'm not experienced enough on computer languages to see it. The first time that I saw this was in a video from Jonathan Blow (https://www.youtube.com/watch?v=UTqZNujQOlA) and it looked like a really good idea. It would be much better that force people to learn another language (the macro language) or any other kind of preprocessor, instead you could use all your knowledge but just at compile time. It can also have good usages apart form generating code, but generating data that can be generated and known at compile time. And allow even to improve the usage of the language (maybe DSL) at a library level.

This is something that could be very interesting! Unfortunately it is definitely out of scope for Swift 3.

-Chris


(Matt Whiteside) #6

I don’t know if something like this has been done before, but I agree, the idea of the compile time version of the language being the same same as the runtime version, is very interesting. +1.

Matt

···

On Dec 20, 2015, at 21:43, Tyler Fleming Cloutier via swift-evolution <swift-evolution@swift.org> wrote:

Woah, Alejandro, thanks for posting this! That talk was super interesting, particularly exciting at 49:48 <https://youtu.be/UTqZNujQOlA?t=49m48s>. That was just plan cool. Jonathan Blow is quite the orthogonal thinker.

+1 for this, or at least to evaluate how it would fit into the language!

Tyler

On Dec 8, 2015, at 12:01 PM, Alejandro Martinez via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hi everyone,

Don't take this mail as an oficial proposal but just as some food for thought, I wanted to talk about this to see what you think about it.

I've been following the list since the "Open Source Day" and I've seen in many instances proposals that could have been solved by a macro system, being just a temporal solution since everything can't be done just now or being a permanent solution if that macro system existed. Some of them may include the thread about "code smells", automatic wrapper synthesis or deriving, or even the topic about forwarding calls automatically to an inner object.

My thinking was how difficult or viable it would be to run Swift code from our programs at compile time. I'm not experienced enough on computer languages to see it. The first time that I saw this was in a video from Jonathan Blow (https://www.youtube.com/watch?v=UTqZNujQOlA <https://www.youtube.com/watch?v=UTqZNujQOlA>) and it looked like a really good idea. It would be much better that force people to learn another language (the macro language) or any other kind of preprocessor, instead you could use all your knowledge but just at compile time. It can also have good usages apart form generating code, but generating data that can be generated and known at compile time. And allow even to improve the usage of the language (maybe DSL) at a library level.

Blow seems like is going one step further and allowing the program to call the compiler as if it was a library and even he talks about allowing it to modify the AST, which is maybe going a little to far away.

Anyway, that's the idea. Obviously is not something to be done in the near future.

And sorry if it doesn't make any sense and I'm just making you lose your time.

Cheers,

Alejandro Martínez
@alexito4
http://alejandromp.com <http://alejandromp.com/>

_______________________________________________
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


(TJ Usiyan) #7

+1

I would like to end up with something incorporating quoted terms, macros,
and compile time evaluation.

···

On Wed, Dec 9, 2015 at 1:10 PM, Alejandro Martinez via swift-evolution < swift-evolution@swift.org> wrote:

Yeah definitely nothing for Swift 3, totally understandable.
I was just curious if it was feasible or just a simple NONO.
Thanks for answering!

Sent from my iPad

> On 09 Dec 2015, at 05:26, Chris Lattner <clattner@apple.com> wrote:
>
>
>> On Dec 8, 2015, at 12:01 PM, Alejandro Martinez via swift-evolution < > swift-evolution@swift.org> wrote:
>>
>> Hi everyone,
>>
>> Don't take this mail as an oficial proposal but just as some food for
thought, I wanted to talk about this to see what you think about it.
>>
>> I've been following the list since the "Open Source Day" and I've seen
in many instances proposals that could have been solved by a macro system,
being just a temporal solution since everything can't be done just now or
being a permanent solution if that macro system existed. Some of them may
include the thread about "code smells", automatic wrapper synthesis or
deriving, or even the topic about forwarding calls automatically to an
inner object.
>>
>> My thinking was how difficult or viable it would be to run Swift code
from our programs at compile time. I'm not experienced enough on computer
languages to see it. The first time that I saw this was in a video from
Jonathan Blow (https://www.youtube.com/watch?v=UTqZNujQOlA) and it looked
like a really good idea. It would be much better that force people to learn
another language (the macro language) or any other kind of preprocessor,
instead you could use all your knowledge but just at compile time. It can
also have good usages apart form generating code, but generating data that
can be generated and known at compile time. And allow even to improve the
usage of the language (maybe DSL) at a library level.
>
> This is something that could be very interesting! Unfortunately it is
definitely out of scope for Swift 3.
>
> -Chris
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Andrew Brown) #8

Definite +1 from me.
Check out elaboration functions from hardware description languages.
Loading constants from files during compile is incredibly useful.

···

On 9 Dec 2015, at 08:47, T.J. Usiyan via swift-evolution <swift-evolution@swift.org> wrote:

+1

I would like to end up with something incorporating quoted terms, macros, and compile time evaluation.

On Wed, Dec 9, 2015 at 1:10 PM, Alejandro Martinez via swift-evolution <swift-evolution@swift.org> wrote:
Yeah definitely nothing for Swift 3, totally understandable.
I was just curious if it was feasible or just a simple NONO.
Thanks for answering!

Sent from my iPad

> On 09 Dec 2015, at 05:26, Chris Lattner <clattner@apple.com> wrote:
>
>
>> On Dec 8, 2015, at 12:01 PM, Alejandro Martinez via swift-evolution <swift-evolution@swift.org> wrote:
>>
>> Hi everyone,
>>
>> Don't take this mail as an oficial proposal but just as some food for thought, I wanted to talk about this to see what you think about it.
>>
>> I've been following the list since the "Open Source Day" and I've seen in many instances proposals that could have been solved by a macro system, being just a temporal solution since everything can't be done just now or being a permanent solution if that macro system existed. Some of them may include the thread about "code smells", automatic wrapper synthesis or deriving, or even the topic about forwarding calls automatically to an inner object.
>>
>> My thinking was how difficult or viable it would be to run Swift code from our programs at compile time. I'm not experienced enough on computer languages to see it. The first time that I saw this was in a video from Jonathan Blow (https://www.youtube.com/watch?v=UTqZNujQOlA) and it looked like a really good idea. It would be much better that force people to learn another language (the macro language) or any other kind of preprocessor, instead you could use all your knowledge but just at compile time. It can also have good usages apart form generating code, but generating data that can be generated and known at compile time. And allow even to improve the usage of the language (maybe DSL) at a library level.
>
> This is something that could be very interesting! Unfortunately it is definitely out of scope for Swift 3.
>
> -Chris
_______________________________________________
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