<div dir="ltr">My code is often abstract and full of generics, but the standard library code does do several things that aren't the swift we all know and love, from my brief tinkering I've seen at least these things:<div> * It defines public protocols dependent on private protocols like <span style="color:rgb(112,61,170);font-family:Menlo;font-size:11px">_MaxBuiltinIntegerType</span><div> * It uses special type annotations like <span style="font-family:Menlo;font-size:11px">@_transparent</span></div><div> * It extensively uses macro-like files (See <font face="monospace, monospace">FixedPoint.swift.gyb</font>)<br></div><div> * The <span style="font-family:Menlo;font-size:11px">Builtin </span>module, where do I find that?</div><div><br></div><div>I think to a certain extent these things are probably necessary to get the work done and make it flexible, and I'm sure the need for them will decrease over time. However it does mean that the dev team doesn't have the same restrictions on design and implementation that we do. This also means that the dev team is essentially using a different version of Swift and that will inform their decisions on what Swift needs and how it should be used.</div><div><br></div><div>As for writing the compiler in Swift, I think this would be great, I haven't read Colin's article yet but it sounds like a valid concern.</div><div><br></div><div>It's a huge undertaking and perhaps something that can be done incrementally by the community as well. Chris Lattner has mentioned in the past that many of the devs working on Swift would love to do this:</div><div><br></div><div>From his twitter (<a href="https://twitter.com/clattner_llvm/status/613906970890801152">https://twitter.com/clattner_llvm/status/613906970890801152</a>):</div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div><span style="font-size:13px;color:rgb(89,132,179);font-family:'Helvetica Neue'">@</span><b style="font-size:13px;color:rgb(89,132,179);font-family:'Helvetica Neue'">siracusa</b> Many of us would love to rewrite the swift compiler in swift - it would crash a lot less, and be a lot more joyful for us.</div></div><div><br></div><div><p style="margin:0px;font-size:13px;line-height:normal;font-family:'Helvetica Neue';color:rgb(77,77,77)"><span style="color:rgb(89,132,179)">@<b>siracusa</b></span> that said, we have a ton of other higher priorities that affect users of swift. Poor compiler hackers just have to suffer for now</p></div></blockquote><div><div><a href="https://twitter.com/clattner_llvm/status/613906586050826241" target="_blank"></a></div></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Dec 20, 2015 at 11:40 AM, Colin Barrett 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"><div style="word-wrap:break-word"><br><div><span class=""><blockquote type="cite"><div>On Dec 19, 2015, at 7:39 PM, Amir Michail <<a href="mailto:a.michail@me.com" target="_blank">a.michail@me.com</a>> wrote:</div><br><div><blockquote type="cite" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br>On Dec 19, 2015, at 7:37 PM, Colin Barrett <<a href="mailto:colin@springsandstruts.com" target="_blank">colin@springsandstruts.com</a>> wrote:<br><br><br><blockquote type="cite">On Dec 19, 2015, at 7:32 PM, Amir Michail <<a href="mailto:a.michail@me.com" target="_blank">a.michail@me.com</a>> wrote:<br><br><br><blockquote type="cite">On Dec 19, 2015, at 7:21 PM, Colin Barrett <<a href="mailto:colin@springsandstruts.com" target="_blank">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" 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></blockquote><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></blockquote><br>Perhaps I don’t understand what you mean, but the article gives two good reasons why compiler code is special.<br></blockquote><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">Compiler standard library code tends to be very abstract and full of generics. Normal code isn’t like that.</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"></div></blockquote><div><br></div></span>Speak for yourself ;-)</div><span class=""><div><br><blockquote type="cite"><div><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><blockquote type="cite" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">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><blockquote type="cite">[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></blockquote><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><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">On Dec 19, 2015, at 4:41 PM, Amir Michail via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br><br>Compiler code is probably more typical of what most programmers write than library code and so would be ideal for suggesting further language evolution ideas.<br>_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></blockquote></blockquote></blockquote></blockquote></div></blockquote></div><br>
</span><img src="https://u2002410.ct.sendgrid.net/wf/open?upn=pQw7h83fWt3LLbgkfL4TSUL0weaZnVFZxDe5GShw4uRLzGJbydNlhtAT9sDS3rnlFVpsPKw8zaLfySiq6lNtkJXfHRc09BXTrEsLRCWq3M10mhAerVJilToWghM6x8-2FI0vuIQ5WAzoOIRlVHl0rOERHkqhr0OnWNJN9EBRaVH9ODwWrOXBy-2B3Bnqm3fmJXNh2DurGCq0w8wYAeThRRKd-2BQ-3D-3D" alt="" width="1" height="1" border="0" style="min-height:1px!important;width:1px!important;border-width:0!important;margin-top:0!important;margin-bottom:0!important;margin-right:0!important;margin-left:0!important;padding-top:0!important;padding-bottom:0!important;padding-right:0!important;padding-left:0!important">
</div>
<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>
<br></blockquote></div><br></div>