4 ms·

> I have filed a radar (Open Radar) asking for an eval() function in Swift. Does anyone else thing that is a really bad idea in general? To do that not only wo

> I have filed a radar (Open Radar) asking for an eval() function in Swift. Does anyone else thing that is a really bad idea in general? To do that not only would type safety go straight out of the window but so would a great many of the compile time optimisations that are currently possible (I don't know how many are being done at this time). Within pure swift the type information can be statically checked at compile time and then the type information can essentially be discarded. To offer eval I don't think that would be possible. It is also probably why there isn't the level of reflection that the OP is wishing for.

nielsbot 12y ago
It would allow for rapid prototyping perhaps
- josephlord 12y ago
  Can you give me an example of what you would expect it to do that can't be done in the Playground and how you would use it? It strikes me as quite an expensive[0] change to make just to support slightly different development models. [0] Potentially requiring different code generation mode embedding type information and other run-time information that wouldn't generally be used and then having a system that can use the information to execute arbitrary code. It might be that much of this is already need for other purposes but I wouldn't assume so without information.
  - emp 12y ago
    Using Injection for XCode gives you live coding close to a Smalltalk system. So you live code on your actual app, super nice for tuning core image filters, or any thing where small iterations are needed between compiles. I literally save hours in a day by not needing a "recompile, relaunch, find my context, repeat" loop.
    - josephlord 12y ago
      I think the intention is that Playgrounds will cover this use case but I can see where the set up is the result of complex and disparate code it might be hard to pull into the Playground and repl in the code is helpful. I do it myself in LLDB and use Pry when working with Ruby/Rails to dig into the state at the context and try things out. I can see this working with a debug build with LLVM/LLDB support. The OP seemed to be picturing a service that could operate in released software and I find that harder to imagine.
    - gress 12y ago
      Code injection for swift would be great, but there is no reason it would have to be done using either eval or message passing. The debug symbols are enough for the compiler to do hot code replacement, either directly or through trampolines.
kodablah 12y ago
I highly doubt it will happen. Apple wants to avoid runtime compilation (which this would be an LLVM runtime deal I assume) on iOS from what I gather about their no-VM-on-iOS policy. Not sure if Apple embeds typing metadata in libraries. If so, I don't see why type checking is impossible, at least for exposed (i.e. @objc) stuff.
Buckleyisms 12y ago
I described that radar rather poorly. If you look at what I described in the radar, I basically want them to ship the swift compiler as part of the core OS, and an eval function would compile its argument and load it into the current process using the dynamic linker. I definitely do not want interpreted Swift. Swift is certainly a language that relies on compiler optimizations. I don't want to change that.
- josephlord 12y ago
  But it would be unable to interact in a symbolic way with the calling app. It might be able to access things in frameworks but it might as well be a separate app that you compile with external tools at that point. As to why it couldn't interact with the running app others have given some examples but it couldn't even reliably call functions as they may be inlined or generics may only be compiled into their required type specific versions. I do expect[0] Apple to open source Swift when it is finally released and it to be part of the LLVM project so you could embed whatever parts make sense in your own applications but it wouldn't be like an eval function as I understand it although you could probably use it to make your own playground system. Basically it would be an LLVM feature/library not a Swift language feature. [0] Guess. I have no inside information and may end up disappointed.
- cjensen 12y ago
  Eval is not a good idea because programmers inevitably have trouble with "Little Bobby Tables"[1]. There is a place for eval. Just not in a language which is going to be used on Grandma's devices. [1] http://xkcd.com/327/ http://xkcd.com/327/

nielsbot 12y ago

It would allow for rapid prototyping perhaps

josephlord 12y ago
Can you give me an example of what you would expect it to do that can't be done in the Playground and how you would use it? It strikes me as quite an expensive[0] change to make just to support slightly different development models. [0] Potentially requiring different code generation mode embedding type information and other run-time information that wouldn't generally be used and then having a system that can use the information to execute arbitrary code. It might be that much of this is already need for other purposes but I wouldn't assume so without information.
- emp 12y ago
  Using Injection for XCode gives you live coding close to a Smalltalk system. So you live code on your actual app, super nice for tuning core image filters, or any thing where small iterations are needed between compiles. I literally save hours in a day by not needing a "recompile, relaunch, find my context, repeat" loop.
  - josephlord 12y ago
    I think the intention is that Playgrounds will cover this use case but I can see where the set up is the result of complex and disparate code it might be hard to pull into the Playground and repl in the code is helpful. I do it myself in LLDB and use Pry when working with Ruby/Rails to dig into the state at the context and try things out. I can see this working with a debug build with LLVM/LLDB support. The OP seemed to be picturing a service that could operate in released software and I find that harder to imagine.
  - gress 12y ago
    Code injection for swift would be great, but there is no reason it would have to be done using either eval or message passing. The debug symbols are enough for the compiler to do hot code replacement, either directly or through trampolines.

kodablah 12y ago

I highly doubt it will happen. Apple wants to avoid runtime compilation (which this would be an LLVM runtime deal I assume) on iOS from what I gather about their no-VM-on-iOS policy. Not sure if Apple embeds typing metadata in libraries. If so, I don't see why type checking is impossible, at least for exposed (i.e. @objc) stuff.

Buckleyisms 12y ago

I described that radar rather poorly. If you look at what I described in the radar, I basically want them to ship the swift compiler as part of the core OS, and an eval function would compile its argument and load it into the current process using the dynamic linker. I definitely do not want interpreted Swift. Swift is certainly a language that relies on compiler optimizations. I don't want to change that.

josephlord 12y ago
But it would be unable to interact in a symbolic way with the calling app. It might be able to access things in frameworks but it might as well be a separate app that you compile with external tools at that point. As to why it couldn't interact with the running app others have given some examples but it couldn't even reliably call functions as they may be inlined or generics may only be compiled into their required type specific versions. I do expect[0] Apple to open source Swift when it is finally released and it to be part of the LLVM project so you could embed whatever parts make sense in your own applications but it wouldn't be like an eval function as I understand it although you could probably use it to make your own playground system. Basically it would be an LLVM feature/library not a Swift language feature. [0] Guess. I have no inside information and may end up disappointed.
cjensen 12y ago
Eval is not a good idea because programmers inevitably have trouble with "Little Bobby Tables"[1]. There is a place for eval. Just not in a language which is going to be used on Grandma's devices. [1] http://xkcd.com/327/ http://xkcd.com/327/