The Case for Message Passing in Swift

Re:The Case for Message Passing in Swift by Buckleyisms on Friday June 27, 2014 @01:42PM (#7955239)

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.

[ Parent | on HN ]

Re:The Case for Message Passing in Swift by josephlord on Friday June 27, 2014 @03:30PM (#7955859)

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.

[ Parent | on HN ]

Re:The Case for Message Passing in Swift by cjensen on Friday June 27, 2014 @08:44PM (#7956981)

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/

[ Parent | on HN ]