[swift-evolution] Proposal: Rewrite Swift compiler in swift to get ideas for further language evolution.
griotspeak at gmail.com
Sat Dec 26 12:06:50 CST 2015
We've asked this a few times. Chris Lattner has said something about it
"There are no short term plans. Unless you’d consider rewriting all of
LLVM as part of the project (something that would be awesome, but that I
wouldn’t recommend :-), we’d need Swift to be able to import C++ APIs. I’m
personally hopeful that we’ll be able to tackle at least some of that in
Swift 4, but we’ll see - no planning can be done for Swift 4 until Swift 3
starts to wind down." - Chris
On Fri, Dec 25, 2015 at 8:26 PM, Andrew Bennett via swift-evolution <
swift-evolution at swift.org> wrote:
> This may address many of the concerns, and perhaps lower the barriers to
> the community contributing:
> How about instead of rewriting the entire compiler in Swift, we just
> rewrite the Swift -> SIL component?
> On Mon, Dec 21, 2015 at 10:54 PM, Jean-Daniel Dupas via swift-evolution <
> swift-evolution at swift.org> wrote:
>> > Le 20 déc. 2015 à 01:37, Colin Barrett via swift-evolution <
>> swift-evolution at swift.org> a écrit :
>> >> On Dec 19, 2015, at 7:32 PM, Amir Michail <a.michail at me.com> wrote:
>> >>> On Dec 19, 2015, at 7:21 PM, Colin Barrett <
>> colin at springsandstruts.com> wrote:
>> >>> I’d recommend you read
>> which has a number of rebuttals to what you’ve said below.
>> >> That’s an interesting article but it doesn’t address the issue of
>> whether compiler code is more like normal programming than compiler
>> standard library code.
>> > Perhaps I don’t understand what you mean, but the article gives two
>> good reasons why compiler code is special. The first reason is that we
>> understand a lot about how to design a compiler, much more than we
>> understand about how to design other types of programs. The second follows:
>> >> [C]ompilers are an atypical class of program. In essence, a compiler
>> is a simple batch pipeline process. A program is read in and translated to
>> a tree; a series of tree transformations are applied; and eventually one of
>> those trees is saved out as some sort of binary data (e.g. machine code or
>> bytecode). Most of the intermediate tree transformations calculate a
>> relatively simple bit of information about the program and create a
>> slightly modified tree based on it. A few calculations crop up time and
>> time again, such as: maps from variables to scopes or types; and stacks to
>> determine closures. Significantly, and unlike most programs in the real
>> world, there is no interaction with users: the compiler knows all it needs
>> about the outside world from the moment it is called.
>> > Personally, I think the main reason not to rewrite the Swift compiler
>> is that it would be a distraction from improving the Swift language and
>> other associated tools.
>> > -Colin
>> An other reason is that is make it harder to port to new platforms. You
>> would have to do all the dev using cross compilation from another platform
>> instead of just working on the target platform directly.
>> swift-evolution mailing list
>> swift-evolution at swift.org
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution