https://github.com/apple/swift/blob/2c7b0b22831159396fe0e98e5944e64a483c356e/www/FAQ.rst
On Sat, Dec 19, 2015 at 5:06 PM, Andrew Bennett via swift-evolution < [email protected]> wrote: > 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: > * It defines public protocols dependent on private protocols like > _MaxBuiltinIntegerType > * It uses special type annotations like @_transparent > * It extensively uses macro-like files (See FixedPoint.swift.gyb) > * The Builtin module, where do I find that? > > 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. > > 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. > > 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: > > From his twitter ( > https://twitter.com/clattner_llvm/status/613906970890801152): > > @*siracusa* 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. > > @*siracusa* that said, we have a ton of other higher priorities that > affect users of swift. Poor compiler hackers just have to suffer for now > > <https://twitter.com/clattner_llvm/status/613906586050826241> > > > On Sun, Dec 20, 2015 at 11:40 AM, Colin Barrett via swift-evolution < > [email protected]> wrote: > >> >> On Dec 19, 2015, at 7:39 PM, Amir Michail <[email protected]> wrote: >> >> >> On Dec 19, 2015, at 7:37 PM, Colin Barrett <[email protected]> >> wrote: >> >> >> On Dec 19, 2015, at 7:32 PM, Amir Michail <[email protected]> wrote: >> >> >> On Dec 19, 2015, at 7:21 PM, Colin Barrett <[email protected]> >> wrote: >> >> I’d recommend you read >> http://tratt.net/laurie/blog/entries/the_bootstrapped_compiler_and_the_damage_done, >> 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. >> >> >> Compiler standard library code tends to be very abstract and full of >> generics. Normal code isn’t like that. >> >> >> Speak for yourself ;-) >> >> >> 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 >> >> On Dec 19, 2015, at 4:41 PM, Amir Michail via swift-evolution < >> [email protected]> wrote: >> >> 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. >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
