1

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.

2

I’d recommend you read Laurence Tratt: The Bootstrapped Compiler and the Damage Done, which has a number of rebuttals to what you’ve said below.

···

On Dec 19, 2015, at 4:41 PM, Amir Michail via swift-evolution <swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

3

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.

Bootstrapping is a large investment with little practical value beside demonstrating that "the child is mature enough for serious work".
That said, flying to the moon has little practical value as well, but I wouldn't say it was a stupid idea...
I'm quite sure that there will be a Swift compiler written in Swift somewhere in the future, and that it will be a proud moment for those involved in the language.

4

I’d recommend you read Laurence Tratt: 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.

···

On Dec 19, 2015, at 7:21 PM, Colin Barrett <colin@springsandstruts.com> wrote:

On Dec 19, 2015, at 4:41 PM, Amir Michail via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

5

I’d recommend you read Laurence Tratt: 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

···

On Dec 19, 2015, at 7:32 PM, Amir Michail <a.michail@me.com> wrote:

On Dec 19, 2015, at 7:21 PM, Colin Barrett <colin@springsandstruts.com> wrote:

On Dec 19, 2015, at 4:41 PM, Amir Michail via swift-evolution <swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

6

I’d recommend you read Laurence Tratt: 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.

···

On Dec 19, 2015, at 7:37 PM, Colin Barrett <colin@springsandstruts.com> wrote:

On Dec 19, 2015, at 7:32 PM, Amir Michail <a.michail@me.com> wrote:

On Dec 19, 2015, at 7:21 PM, Colin Barrett <colin@springsandstruts.com> wrote:

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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

7

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

···

Le 20 déc. 2015 à 01:37, Colin Barrett via swift-evolution <swift-evolution@swift.org> a écrit :

On Dec 19, 2015, at 7:32 PM, Amir Michail <a.michail@me.com> wrote:

On Dec 19, 2015, at 7:21 PM, Colin Barrett <colin@springsandstruts.com> wrote:

I’d recommend you read Laurence Tratt: 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

8

I’d recommend you read Laurence Tratt: 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 ;-)

···

On Dec 19, 2015, at 7:39 PM, Amir Michail <a.michail@me.com> wrote:

On Dec 19, 2015, at 7:37 PM, Colin Barrett <colin@springsandstruts.com> wrote:

On Dec 19, 2015, at 7:32 PM, Amir Michail <a.michail@me.com> wrote:

On Dec 19, 2015, at 7:21 PM, Colin Barrett <colin@springsandstruts.com> wrote:

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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

9

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@swift.org> wrote:

> Le 20 déc. 2015 à 01:37, Colin Barrett via swift-evolution < > swift-evolution@swift.org> a écrit :
>
>
>> On Dec 19, 2015, at 7:32 PM, Amir Michail <a.michail@me.com> wrote:
>>
>>
>>> On Dec 19, 2015, at 7:21 PM, Colin Barrett <colin@springsandstruts.com> > wrote:
>>>
>>> I’d recommend you read
Laurence Tratt: 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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

10

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,
* 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&gt;

···

from my brief tinkering I've seen at least these things:

On Sun, Dec 20, 2015 at 11:40 AM, Colin Barrett via swift-evolution < swift-evolution@swift.org> wrote:

On Dec 19, 2015, at 7:39 PM, Amir Michail <a.michail@me.com> wrote:

On Dec 19, 2015, at 7:37 PM, Colin Barrett <colin@springsandstruts.com> > wrote:

On Dec 19, 2015, at 7:32 PM, Amir Michail <a.michail@me.com> wrote:

On Dec 19, 2015, at 7:21 PM, Colin Barrett <colin@springsandstruts.com> > wrote:

I’d recommend you read
Laurence Tratt: 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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

11

We've asked this a few times. Chris Lattner has said something about it
already.

"There are no short term plans. Unless you’d consider rewriting all of
LLVM as part of the project (something that would be awesome, but that I
wouldn’t recommend :-), we’d need Swift to be able to import C++ APIs. I’m
personally hopeful that we’ll be able to tackle at least some of that in
Swift 4, but we’ll see - no planning can be done for Swift 4 until Swift 3
starts to wind down." - Chris

···

On Fri, Dec 25, 2015 at 8:26 PM, Andrew Bennett via swift-evolution < swift-evolution@swift.org> wrote:

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@swift.org> wrote:

> Le 20 déc. 2015 à 01:37, Colin Barrett via swift-evolution < >> swift-evolution@swift.org> a écrit :
>
>
>> On Dec 19, 2015, at 7:32 PM, Amir Michail <a.michail@me.com> wrote:
>>
>>
>>> On Dec 19, 2015, at 7:21 PM, Colin Barrett < >> colin@springsandstruts.com> wrote:
>>>
>>> I’d recommend you read
Laurence Tratt: 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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

12

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 <swift-evolution@swift.org> 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\):
@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&gt;

On Sun, Dec 20, 2015 at 11:40 AM, Colin Barrett via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Dec 19, 2015, at 7:39 PM, Amir Michail <a.michail@me.com <mailto:a.michail@me.com>> wrote:

On Dec 19, 2015, at 7:37 PM, Colin Barrett <colin@springsandstruts.com <mailto:colin@springsandstruts.com>> wrote:

On Dec 19, 2015, at 7:32 PM, Amir Michail <a.michail@me.com <mailto:a.michail@me.com>> wrote:

On Dec 19, 2015, at 7:21 PM, Colin Barrett <colin@springsandstruts.com <mailto:colin@springsandstruts.com>> wrote:

I’d recommend you read Laurence Tratt: 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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

13
···

On Sat, Dec 19, 2015 at 5:06 PM, Andrew Bennett via swift-evolution < swift-evolution@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&gt;

On Sun, Dec 20, 2015 at 11:40 AM, Colin Barrett via swift-evolution < > swift-evolution@swift.org> wrote:

On Dec 19, 2015, at 7:39 PM, Amir Michail <a.michail@me.com> wrote:

On Dec 19, 2015, at 7:37 PM, Colin Barrett <colin@springsandstruts.com> >> wrote:

On Dec 19, 2015, at 7:32 PM, Amir Michail <a.michail@me.com> wrote:

On Dec 19, 2015, at 7:21 PM, Colin Barrett <colin@springsandstruts.com> >> wrote:

I’d recommend you read
Laurence Tratt: 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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution