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

Andrew Bennett cacoyi at gmail.com
Fri Dec 25 20:26:32 CST 2015

This may address many of the concerns, and perhaps lower the barriers to
the community contributing:
     How about instead of rewriting the entire compiler in Swift, we just
rewrite the Swift -> SIL component?

On Mon, Dec 21, 2015 at 10:54 PM, Jean-Daniel Dupas via swift-evolution <
swift-evolution at swift.org> wrote:

> > Le 20 déc. 2015 à 01:37, Colin Barrett via swift-evolution <
> swift-evolution at swift.org> a écrit :
> >
> >
> >> 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. 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
> >
> 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.
> Jean-Daniel
> _______________________________________________
> 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/20151226/f3589a75/attachment.html>

More information about the swift-evolution mailing list