Beyond whether or not a standard library provides a better simulation of "actual programming" than a standard library, making a Swift compiler in Swift is a massive undertaking. The Go maintainers started working on a self-hosting compiler 3 years after the language's initial release and it took them another two years to get it right.
Félix > Le 19 déc. 2015 à 20:06:48, Andrew Bennett via swift-evolution > <[email protected]> a écrit : > > 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 > <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] <mailto:[email protected]>> wrote: > >> On Dec 19, 2015, at 7:39 PM, Amir Michail <[email protected] >> <mailto:[email protected]>> wrote: >> >>> >>> On Dec 19, 2015, at 7:37 PM, Colin Barrett <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> >>>> On Dec 19, 2015, at 7:32 PM, Amir Michail <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> >>>>> On Dec 19, 2015, at 7:21 PM, Colin Barrett <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> >>>>> I’d recommend you read >>>>> http://tratt.net/laurie/blog/entries/the_bootstrapped_compiler_and_the_damage_done >>>>> >>>>> <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] <mailto:[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] <mailto:[email protected]> >>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> > > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > > > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
