[swift-evolution] Proposal: Rewrite Swift compiler in swift to get ideas for further language evolution.

[J. Cheyo Jimenez]

https://github.com/apple/swift/blob/2c7b0b22831159396fe0e98e5944e64a483c356e/www/FAQ.rst

On Sat, Dec 19, 2015 at 5:06 PM, Andrew Bennett via swift-evolution <
swift-evolution at swift.org> 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 <
> swift-evolution at swift.org> wrote:
>
>>
>> On Dec 19, 2015, at 7:39 PM, Amir Michail <a.michail at me.com> wrote:
>>
>>
>> On Dec 19, 2015, at 7:37 PM, Colin Barrett <colin at springsandstruts.com>
>> wrote:
>>
>>
>> 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
>> 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 <
>> swift-evolution at swift.org> 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
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151220/2c97cf8d/attachment.html>