<div dir="ltr">This may address many of the concerns, and perhaps lower the barriers to the community contributing:<div> How about instead of rewriting the entire compiler in Swift, we just rewrite the Swift -> SIL component?</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 21, 2015 at 10:54 PM, Jean-Daniel Dupas via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> Le 20 déc. 2015 à 01:37, Colin Barrett via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> a écrit :<br>
><br>
><br>
>> On Dec 19, 2015, at 7:32 PM, Amir Michail <<a href="mailto:a.michail@me.com">a.michail@me.com</a>> wrote:<br>
>><br>
>><br>
>>> On Dec 19, 2015, at 7:21 PM, Colin Barrett <<a href="mailto:colin@springsandstruts.com">colin@springsandstruts.com</a>> wrote:<br>
>>><br>
>>> I’d recommend you read <a href="http://tratt.net/laurie/blog/entries/the_bootstrapped_compiler_and_the_damage_done" rel="noreferrer" target="_blank">http://tratt.net/laurie/blog/entries/the_bootstrapped_compiler_and_the_damage_done</a>, which has a number of rebuttals to what you’ve said below.<br>
>>><br>
>><br>
>> 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.<br>
><br>
> 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:<br>
><br>
>> [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.<br>
><br>
> 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.<br>
><br>
> -Colin<br>
><br>
<br>
</span>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.<br>
<br>
Jean-Daniel<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</div></div></blockquote></div><br></div>