Initial gh-pages commit

7 files changed, 996 insertions, 0 deletions

diff --git a/blog/2015/10/23/dotty-compiler-bootstraps.html b/blog/2015/10/23/dotty-compiler-bootstraps.html
new file mode 100644
index 000000000..58e478190
--- /dev/null
+++ b/blog/2015/10/23/dotty-compiler-bootstraps.html
@@ -0,0 +1,54 @@
+<p>The <a href="https://github.com/lampepfl/dotty">Dotty project</a>
+is a platform to develop new technology for Scala
+tooling and to try out concepts of future Scala language versions.
+Its compiler is a new design intended to reflect the
+lessons we learned from work with the Scala compiler. A clean redesign
+today will let us iterate faster with new ideas in the future.</p>
+<p>Today we reached an important milestone: the Dotty compiler can
+compile itself, and the compiled compiler can act as a drop-in for the
+original one. This is what one calls a <em>bootstrap</em>.</p>
+<!--more-->
+<h2><a href="#why-is-this-important" id="why-is-this-important">Why is this important?</a></h2>
+<p>The main reason is that this gives us a some validation of the
+<em>trustworthiness</em> of the compiler itself. Compilers are complex beasts,
+and many things can go wrong. By far the worst things that can go
+wrong are bugs where incorrect code is produced. It's not fun debugging code that looks perfectly
+fine, yet gets translated to something subtly wrong by the compiler.</p>
+<p>Having the compiler compile itself is a good test to demonstrate that
+the generated code has reached a certain level of quality. Not only is
+a compiler a large program (44k lines in the case of dotty), it is
+also one that exercises a large part of the language in quite
+intricate ways. Moreover, bugs in the code of a compiler don't tend to
+go unnoticed, precisely because every part of a compiler feeds into
+other parts and all together are necessary to produce a correct
+translation.</p>
+<h2><a href="#are-we-done-yet" id="are-we-done-yet">Are we done yet?</a></h2>
+<p>Far from it! The compiler is still very rough. A lot more work is
+needed to</p>
+<ul>
+<li>make it more robust, in particular when analyzing incorrect programs,</li>
+<li>improve error messages and warnings,</li>
+<li>improve the efficiency of some of the generated code,</li>
+<li>improve compilation speed,</li>
+<li>embed it in external tools such as sbt, REPL, IDEs,</li>
+<li>remove restrictions on what Scala code can be compiled,</li>
+<li>help in migrating Scala code that will have to be changed.</li>
+</ul>
+<h2><a href="#what-are-the-next-steps" id="what-are-the-next-steps">What are the next steps?</a></h2>
+<p>Over the coming weeks and months, we plan to work on the following topics:</p>
+<ul>
+<li>Make snapshot releases.</li>
+<li>Work on SBT integration of the compiler.</li>
+<li>Work on IDE support.</li>
+<li>Investigate the best way to obtaining a REPL.</li>
+<li>Work on the build infrastructure.</li>
+</ul>
+<p>If you want to get your hands dirty with any of this, now is a good
+moment to get involved! Join the team of contributors, including
+Dmitry Petrashko (<a href="https://github.com/DarkDimius">@DarkDimius</a>),
+Guillaume Martres (<a href="https://github.com/smarter">@smarter</a>),
+Ondrey Lhotak (<a href="https://github.com/olhotak">@olhotak</a>),
+Samuel Gruetter (<a href="https://github.com/samuelgruetter">@samuelgruetter</a>),
+Vera Salvis (<a href="https://github.com/vsalvis">@vsalvis</a>),
+and Jason Zaugg (<a href="https://github.com/retronym">@retronym</a>).</p>
+<p>To get started: <a href="https://github.com/lampepfl/dotty">https://github.com/lampepfl/dotty</a>.</p>
diff --git a/blog/2016/01/02/new-year-resolutions.html b/blog/2016/01/02/new-year-resolutions.html
new file mode 100644
index 000000000..7575ab240
--- /dev/null
+++ b/blog/2016/01/02/new-year-resolutions.html
@@ -0,0 +1,48 @@
+<p>For most of us, the change of the year is an occasion for thinking
+about what we missed doing last year and where we want to improve. I decided
+there are a couple of things where I would like to do better in 2016
+than in 2015. The first is that I would like to do more blogging and
+writing in general. I have been pretty silent for most of the last
+year. This was mostly caused by the fact that I had been heads down to
+work on DOT, Scala's foundations, and <em>dotty</em>, the new Scala compiler
+platform we are working on. It's been a lot of work, but we are finally
+getting good results. DOT now has a mechanized proof of type soundness
+and the dotty compiler <a href="http://www.scala-lang.org/blog/2015/10/23/dotty-compiler-bootstraps.html">can now compile
+itself</a>
+as well as large parts of Scala's standard library.</p>
+<p>The dotty compiler has a completely new and quite unusual
+architecture, which makes it resemble a functional database or a
+functional reactive program. My <a href="https://www.youtube.com/watch?v=WxyyJyB_Ssc">talk at the JVM language
+summit</a> gives an
+overview. In the coming months I want to write together with my
+collaborators a series of blog posts
+that explain details of the code base. The
+aim of these posts will be to present the new architectural patterns
+to a larger audience and also to help existing and potential
+contributors get familiar with the code base.</p>
+<p>My second resolution is to take a larger effort to promote simplicity
+in Scala. I believe the recent <a href="http://jimplush.com/talk/2015/12/19/moving-a-team-from-scala-to-golang/">blog post by Jim
+Plush</a> should be a wakeup call for our
+community. Scala is a very powerful and un-opinionated language.  This
+means we have a large spectrum of choice how to write a Scala
+application or library. It's very important for all of us to use this
+power wisely, and to promote simplicity of usage wherever possible.
+Unfortunately, most of us fall all too easily into the complexity
+trap, as Alex Payne's tweet sums it up very nicely.</p>
+<blockquote class="twitter-tweet" lang="en"><p lang="en" dir="ltr">“Complexity is like a bug light for smart people. We can&#39;t resist it, even though we know it&#39;s bad for us.” <a href="https://t.co/V9Izi573CF">https://t.co/V9Izi573CF</a></p>&mdash; Alex Payne (@al3x) <a href="https://twitter.com/al3x/status/683036775942496256">January 1, 2016</a></blockquote>
+<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>
+<p>I have been as guilty of complication as everybody else. Is
+<code>CanBuildFrom</code> the most appropriate solution to deal with the
+constraints of embedding special types such as arrays and strings in a
+collection library? It achieves its purpose of providing a uniform
+user-level API on disparate datatypes. But I now think with more
+effort we might be able come up with a solution that works as well and
+is simpler. Another example, where I have doubts if not regrets are
+the <code>/:</code> and <code>:\</code> operators in scala.collections.  They are cute
+synonyms for folds, and I am still fond of the analogy with falling
+dominoes they evoke. But in retrospect I think maybe they did give a
+bad example for others to go overboard with symbolic operators.</p>
+<p>So my main agenda for the coming year is to work on making Scala
+simpler: The language, its foundations, its libraries. I hope you
+will join me in that venture.</p>
+<p>With that thought, I wish you a happy new year 2016.</p>
diff --git a/blog/2016/02/03/essence-of-scala.html b/blog/2016/02/03/essence-of-scala.html
new file mode 100644
index 000000000..78d594b0a
--- /dev/null
+++ b/blog/2016/02/03/essence-of-scala.html
@@ -0,0 +1,128 @@
+<p>What do you get if you boil Scala on a slow flame and wait until all
+incidental features evaporate and only the most concentrated essence
+remains? After doing this for 8 years we believe we have the answer:
+it's DOT, the calculus of dependent object types, that underlies Scala.</p>
+<p>A <a href="http://infoscience.epfl.ch/record/215280">paper on DOT</a> will be
+presented in April at <a href="http://events.inf.ed.ac.uk/wf2016">Wadlerfest</a>,
+an event celebrating Phil Wadler's 60th birthday. There's also a prior
+technical report (<a href="http://arxiv.org/abs/1510.05216">From F to DOT</a>)
+by Tiark Rompf and Nada Amin describing a slightly different version
+of the calculus. Each paper describes a proof of type soundness that
+has been machine-checked for correctness.</p>
+<h2><a href="#the-dot-calculus" id="the-dot-calculus">The DOT calculus</a></h2>
+<p>A calculus is a kind of mini-language that is small enough to be
+studied formally. Translated to Scala notation, the language covered
+by DOT is described by the following abstract grammar:</p>
+<pre><code>Value       v  =  (x: T) =&gt; t            Function
+                  new { x: T =&gt; ds }     Object
+
+Definition  d  =  def a = t              Method definition
+                  type A = T             Type
+
+Term        t  =  v                      Value
+                  x                      Variable
+                  t1(t2)                 Application
+                  t.a                    Selection
+                  { val x = t1; t2 }     Local definition
+
+Type        T  =  Any                    Top type
+                  Nothing                Bottom type
+                  x.A                    Selection
+                  (x: T1) =&gt; T2          Function
+                  { def a: T }           Method declaration
+                  { type T &gt;: T1 &lt;: T2 } Type declaration
+                  T1 &amp; T2                Intersection
+                  { x =&gt; T }             Recursion
+</code></pre>
+<p>The grammar uses several kinds of names:</p>
+<pre><code>x      for (immutable) variables
+a      for (parameterless) methods
+A      for types
+</code></pre>
+<p>The full calculus adds to this syntax formal <em>typing rules</em> that
+assign types <code>T</code> to terms <code>t</code> and formal <em>evaluation rules</em> that
+describe how a program is evaluated. The following <em>type soundness</em>
+property was shown with a mechanized, (i.e. machine-checked) proof:</p>
+<blockquote>
+<p>If a term <code>t</code> has type <code>T</code>, and the evaluation of <code>t</code> terminates, then
+the result of the evaluation will be a value <code>v</code> of type <code>T</code>.</p>
+</blockquote>
+<h2><a href="#difficulties" id="difficulties">Difficulties</a></h2>
+<p>Formulating the precise soundness theorem and proving it was unexpectedly hard,
+because it uncovered some technical challenges that had not been
+studied in depth before. In DOT - as well as in many programming languages -
+you can have conflicting definitions. For instance you might have an abstract
+type declaration in a base class with two conflicting aliases in subclasses:</p>
+<pre><code> trait Base { type A }
+ trait Sub1 extends Base { type A = String }
+ trait Sub2 extends Base { type A = Int }
+ trait Bad extends Sub1 with Sub2
+</code></pre>
+<p>Now, if you combine <code>Sub1</code> and <code>Sub2</code> in trait <code>Bad</code> you get a conflict,
+since the type <code>A</code> is supposed to be equal to both <code>String</code> and <code>Int</code>. If you do
+not detect the conflict and assume the equalities at face value you
+get <code>String = A = Int</code>, hence by transitivity <code>String = Int</code>! Once you
+are that far, you can of course engineer all sorts of situations where
+a program will typecheck but cause a wrong execution at runtime. In
+other words, type soundness is violated.</p>
+<p>Now, the problem is that one cannot always detect these
+inconsistencies, at least not by a local analysis that does not need
+to look at the whole program. What's worse, once you have an
+inconsistent set of definitions you can use these definitions to
+&quot;prove&quot; their own consistency - much like a mathematical theory that
+assumes <code>true = false</code> can &quot;prove&quot; every proposition including its own
+correctness.</p>
+<p>The crucial reason why type soundness still holds is this: If one
+compares <code>T</code> with an alias, one does so always relative to some <em>path</em>
+<code>x</code> that refers to the object containing <code>T</code>.  So it's really <code>x.T = Int</code>. Now, we can show that during evaluation every such path refers
+to some object that was created with a <code>new</code>, and that, furthermore,
+every such object has consistent type definitions. The tricky bit is
+to carefully distinguish between the full typing rules, which allow
+inconsistencies, and the typing rules arising from runtime values,
+which do not.</p>
+<h2><a href="#why-is-this-important" id="why-is-this-important">Why is This Important?</a></h2>
+<p>There are at least four reasons why insights obtained in the DOT
+project are important.</p>
+<ol>
+<li>
+<p>They give us a well-founded explanation of <em>nominal typing</em>.
+Nominal typing means that a type is distinguished from others
+simply by having a different name.
+For instance, given two trait definitions</p>
+<pre><code>  trait A extends AnyRef { def f: Int }
+  trait B extends AnyRef { def f: Int }
+</code></pre>
+<p>we consider <code>A</code> and <code>B</code> to be different types, even though both
+traits have the same parents and both define the same members.
+The opposite of
+nominal typing is structural typing, which treats types
+that have the same structure as being the same. Most programming
+languages are at least in part nominal whereas most formal type systems,
+including DOT, are structural. But the abstract types in DOT
+provide a way to express nominal types such as classes and traits.
+The Wadlerfest paper contains examples that show how
+one can express classes for standard types such as <code>Boolean</code> and <code>List</code> in DOT.</p>
+</li>
+<li>
+<p>They give us a stable basis on which we can study richer languages
+that resemble Scala more closely. For instance, we can encode
+type parameters as type members of objects in DOT. This encoding
+can give us a better understanding of the interactions of
+subtyping and generics. It can explain why variance rules
+are the way they are and what the precise typing rules for
+wildcard parameters <code>[_ &lt;: T]</code>, <code>[_ &gt;: T]</code> should be.</p>
+</li>
+<li>
+<p>DOT also provides a blueprint for Scala compilation. The new Scala
+compiler <em>dotty</em> has internal data structures that closely resemble DOT.
+In particular, type parameters are immediately mapped to type members,
+in the way we propose to encode them also in the calculus.</p>
+</li>
+<li>Finally, the proof principles explored in the DOT work give us guidelines
+to assess and treat other possible soundness issues. We now know much
+better what conditions must be fulfilled to ensure type soundness.
+This lets us put other constructs of the Scala language to the test,
+either to increase our confidence that they are indeed sound, or
+to show that they are unsound. In my next blog I will
+present some of the issues we have discovered through that exercise.</li>
+</ol>
diff --git a/blog/2016/02/17/scaling-dot-soundness.html b/blog/2016/02/17/scaling-dot-soundness.html
new file mode 100644
index 000000000..8da66e692
--- /dev/null
+++ b/blog/2016/02/17/scaling-dot-soundness.html
@@ -0,0 +1,130 @@
+<p>In my <a href="http://www.scala-lang.org/blog/2016/02/03/essence-of-scala.html">last
+blog post</a>
+I introduced DOT, a minimal calculus that underlies much of Scala.
+DOT is much more than an academic exercise, because it gives us
+guidelines on how to design a sound type system for full Scala.</p>
+<h2><a href="#recap-the-problem-of-bad-bounds" id="recap-the-problem-of-bad-bounds">Recap: The Problem of Bad Bounds</a></h2>
+<p>As was argued in the previous blog post, the danger a path-dependent type
+system like Scala's faces is inconsistent bounds or aliases. For
+instance, you might have a type alias</p>
+<pre><code>  type T = String
+</code></pre>
+<p>in scope in some part of the program, but in another part the same
+type member <code>T</code> is known as</p>
+<pre><code>  type T = Int
+</code></pre>
+<p>If you connect the two parts, you end up allowing assigning a <code>String</code>
+to an <code>Int</code> and vice versa, which is unsound - it will crash at
+runtime with a <code>ClassCastException</code>. The problem is that there
+is no obvious, practical, compile time analysis for DOT or
+Scala that ensures that all types have good bounds. Types can contain
+abstract type members with bounds that can be refined elsewhere and
+several independent refinements might lead together to a bad bound
+problem.  Barring a whole program analysis there is no specific
+point in the program where we can figure this out straightforwardly.</p>
+<p>In DOT, the problem is resolved by insisting that every path prefix <code>p</code>
+of a type <code>p.T</code> is at runtime a concrete value. That way, we only have
+to check for good bounds when objects are <em>created</em> with <code>new</code>, and
+that check is easy: When objects are created, we know their class and
+we can insist that all nested types in that class are aliases or
+have consistent bounds. So far so good.</p>
+<h2><a href="#loopholes-caused-by-scaling-up" id="loopholes-caused-by-scaling-up">Loopholes Caused by Scaling Up</a></h2>
+<p>But if we want to scale up the DOT result for full Scala, several
+loopholes open up. These come all down to the fact that the prefix of
+a type selection might <em>not</em> be a value that's constructed with a
+<code>new</code> at run time.  The loopholes can be classified into three
+categories:</p>
+<ol>
+<li>
+<p>The prefix value might be lazy, and never instantiated to anything, as in:</p>
+<pre><code>lazy val p: S = p
+... p.T ...
+</code></pre>
+<p>Note that trying to access the lazy value <code>p</code> would result in an infinite loop. But using <code>p</code> in a type does not force its evaluation, so we might never evaluate <code>p</code>. Since <code>p</code> is not initialized with a <code>new</code>, bad bounds for <code>T</code> would go undetected.</p>
+</li>
+<li>
+<p>The prefix value might be initialized to <code>null</code>, as in</p>
+<pre><code>val p: S = null
+... p.T ...
+</code></pre>
+<p>The problem here is similar to the first one. <code>p</code> is not initialized
+with a <code>new</code> so we know nothing about the bounds of <code>T</code>.</p>
+</li>
+<li>The prefix might be a type <code>T</code> in a type projection <code>T # A</code>, where <code>T</code>
+is not associated with a runtime value.</li>
+</ol>
+<p>We can in fact construct soundness issues in all of these cases. Look
+at the discussion for issues <a href="https://github.com/lampepfl/dotty/issues/50">#50</a>
+and <a href="https://github.com/lampepfl/dotty/issues/1050">#1050</a> in the
+<a href="https://github.com/lampepfl/dotty/issues/1050">dotty</a> repository
+on GitHub. All issues work fundamentally in the same way: Construct a type <code>S</code>
+which has a type member <code>T</code> with bad bounds, say</p>
+<pre><code>Any &lt;: T &lt;: Nothing
+</code></pre>
+<p>Then, use the left subtyping to turn an expression of type <code>Any</code> into
+an expression of type <code>T</code> and use the right subtyping to turn that
+expression into an expression of type <code>Nothing</code>:</p>
+<pre><code>def f(x: Any): p.T = x
+def g(x: p.T): Nothing = x
+</code></pre>
+<p>Taken together, <code>g(f(x))</code> will convert every expression into an
+expression of type <code>Nothing</code>. Since <code>Nothing</code> is a subtype of every
+other type, this means you can convert an arbitrary expression to have
+any type you choose. Such a feat is an impossible promise, of
+course. The promise is usually broken at run-time by failing with a
+<code>ClassCastException</code>.</p>
+<h2><a href="#plugging-the-loopholes" id="plugging-the-loopholes">Plugging the Loopholes</a></h2>
+<p>To get back to soundness we need to plug the loopholes. Some of the
+necessary measures are taken in pull request <a href="https://github.com/lampepfl/dotty/issues/1051">#1051</a>.
+That pull request</p>
+<ul>
+<li>tightens the rules for overrides of lazy values: lazy values
+cannot override or implement non-lazy values,</li>
+<li>tightens the rules which lazy values can appear in paths: they
+must be final and must have concrete types with known consistent bounds,</li>
+<li>allows type projections <code>T # A</code> only if <code>T</code> is a concrete type
+with known consistent bounds.</li>
+</ul>
+<p>It looks like this is sufficient to plug soundness problems (1) and
+(3). To plug (2), we need to make the type system track nullability in
+more detail than we do it now. Nullability tracking is a nice feature
+in its own right, but now we have an added incentive for implementing
+it: it would help to ensure type soundness.</p>
+<p>There's one sub-case of nullability checking which is much harder to do
+than the others. An object reference <code>x.f</code> might be <code>null</code> at run time
+because the field <code>f</code> is not yet initialized. This can lead to a
+soundness problem, but in a more roundabout way than the other issues
+we have identified. In fact, Scala guarantees that in a program that
+runs to completion without aborting, every field will eventually be
+initialized, so every non-null field will have good bounds. Therefore,
+the only way an initialized field <code>f</code> could cause a soundness problem
+is if the program in question would never get to initialize <code>f</code>,
+either because it goes into an infinite loop or because it aborts with
+an exception or <code>System.exit</code> call before reaching the initialization
+point of <code>f</code>. It's a valid question whether type soundness guarantees
+should extend to this class of &quot;strange&quot; programs. We might want to
+draw the line here and resort to runtime checks or exclude &quot;strange&quot;
+programs from any soundness guarantees we can give. The research community
+has coined the term <a href="http://soundiness.org/">soundiness</a> for
+this kind of approach and has <a href="http://cacm.acm.org/magazines/2015/2/182650-in-defense-of-soundiness/fulltext">advocated</a> for it.</p>
+<p>The necessary restrictions on type projection <code>T # A</code> are problematic
+because they invalidate some idioms in type-level programming. For
+instance, the cute trick of making Scala's type system Turing complete
+by having it <a href="https://michid.wordpress.com/2010/01/29/scala-type-level-encoding-of-the-ski-calculus/">simulate SK
+combinators</a>
+would no longer work since that one relies on unrestricted type
+projections. The same holds for some of the encodings of type-level
+arithmetic.</p>
+<p>To ease the transition, we will continue for a while to allow unrestricted type
+projections under a flag, even though they are potentially
+unsound. In the current dotty compiler, that flag is a language import
+<code>-language:Scala2</code>, but it could be something different for other
+compilers, e.g. <code>-unsafe</code>.  Maybe we can find rules that are less
+restrictive than the ones we have now, and are still sound.  But one
+aspect should be non-negotiable: Any fundamental deviations from the
+principles laid down by DOT needs to be proven mechanically correct
+just like DOT was. We have achieved a lot with the DOT proofs, so we
+should make sure not to back-slide. And if the experience of the past
+10 years has taught us one thing, it is that the meta theory of type
+systems has many more surprises in store than one might think. That's
+why mechanical proofs are essential.</p>
diff --git a/blog/2016/05/05/multiversal-equality.html b/blog/2016/05/05/multiversal-equality.html
new file mode 100644
index 000000000..07c62e701
--- /dev/null
+++ b/blog/2016/05/05/multiversal-equality.html
@@ -0,0 +1,46 @@
+<p>I have been working recently on making equality tests using <code>==</code> and <code>!=</code> safer in Scala. This has led to a <a href="https://github.com/lampepfl/dotty/issues/1247">Language Enhancement Proposal</a> which I summarize in this blog.</p>
+<h2><a href="#why-change-equality" id="why-change-equality">Why Change Equality?</a></h2>
+<p>Scala prides itself of its strong static type system. Its type discipline is particularly useful when it comes to refactoring. Indeed, it's possible to write programs in such a way that refactoring problems show up with very high probability as type errors. This is essential for being able to refactor with the confidence that nothing will break. And the ability to do such refactorings is in turn very important for keeping code bases from rotting.</p>
+<p>Of course, getting such a robust code base requires the cooperation of the developers. They should avoid type <code>Any</code>, casts, <a href="http://c2.com/cgi/wiki?StringlyTyped">stringly typed</a> logic, and more generally any operation over loose types that do not capture the important properties of a value. Unfortunately, there is one area in Scala where such loose types are very hard to avoid: That's equality. Comparisons with <code>==</code> and <code>!=</code> are <em>universal</em>. They compare any two values, no matter what their types are. This causes real problems for writing code and more problems for refactoring it.</p>
+<p>For instance, one might want to introduce a proxy for some data structure so that instead of accessing the data structure directly one goes through the proxy. The proxy and the underlying data would have different types. Normally this should be an easy refactoring. If one passes by accident a proxy for the underlying type or <em>vice versa</em> the type checker will flag the error. However, if one accidentally compares a proxy with the underlying type using <code>==</code> or a pattern match, the program is still valid, but will just always say <code>false</code>.  This is a real worry in practice. I recently abandoned a desirable extensive refactoring because I feared that it would be too hard to track down such errors.</p>
+<h2><a href="#where-are-we-today" id="where-are-we-today">Where Are We Today?</a></h2>
+<p>The problems of universal equality in Scala are of course well known. Some libraries have tried to fix it by adding another equality operator with more restricted typing. Most often this safer equality is written <code>===</code>. While <code>===</code> is certainly useful, I am not a fan of adding another equality operator to the language and core libraries. It would be much better if we could fix <code>==</code> instead. This would be both simpler and would catch all potential equality problems including those related to pattern matching.</p>
+<p>How can <code>==</code> be fixed? It looks much harder to do this than adding an alternate equality operator. First, we have to keep backwards compatibility. The ability to compare everything to everything is by now baked into lots of code and libraries.  Second, with just one equality operator we need to make this operator work in all cases where it makes sense. An alternative <code>===</code> operator can choose to refuse some comparisons that should be valid because there's always <code>==</code> to fall back to. With a unique <code>==</code> operator we do not have this luxury.</p>
+<p>The current status in Scala is that the compiler will give warnings for <em>some</em> comparisons that are always <code>false</code>. But the coverage is weak. For instance this will give a warning:</p>
+<pre><code>scala&gt; 1 == &quot;abc&quot;
+&lt;console&gt;:12: warning: comparing values of types Int and String using `==' will always yield false
+</code></pre>
+<p>But this will not:</p>
+<pre><code>scala&gt; &quot;abc&quot; == 1
+res2: Boolean = false
+</code></pre>
+<p>There are also cases where a warning is given for a valid equality test that actually makes sense because the result could be <code>true</code>. In summary, the current checking catches some obvious bugs, which is nice. But it is far too weak and fickle to be an effective refactoring aid.</p>
+<h2><a href="#whats-proposed" id="whats-proposed">What's Proposed?</a></h2>
+<p>I believe to do better, we need to enlist the cooperation of developers. Ultimately it's the developer who provides implementations of equality methods and who is therefore best placed to characterize which equalities make sense. Sometimes this characterization can be involved. For instance, an <code>Int</code> can be compared to other primitive numeric values or to instances of type <code>java.lang.Number</code> but any other comparison will always yield <code>false</code>. Or, it makes sense to compare two <code>Option</code> values if and only if it makes sense to compare the optional element values.</p>
+<p>The best known way to characterize such relationships is with type classes. Implicit values of a trait <code>Eq[T, U]</code> can capture the property that values of type <code>T</code> can be compared to values of type <code>U</code>. Here's the definition of <code>Eq</code></p>
+<pre><code>package scala
+
+trait Eq[-T, -U]
+</code></pre>
+<p>That is, <code>Eq</code> is a pure marker trait with two type parameters and without any members.  Developers can define equality classes by giving implicit <code>Eq</code> instances. Here is a simple one:</p>
+<pre><code>implicit def eqString: Eq[String, String] = Eq
+</code></pre>
+<p>This states that strings can be only compared to strings, not to values of other types.  Here's a more complicated <code>Eq</code> instance:</p>
+<pre><code>implicit def eqOption[T, U](implicit _eq: Eq[T, U]): Eq[Option[T], Option[U]] = Eq
+</code></pre>
+<p>This states that <code>Option</code> values can be compared if their elements can be compared.</p>
+<p>It's foreseen that such <code>Eq</code> instances can be generated automatically. If we add an annotation <code>@equalityClass</code> to <code>Option</code> like this</p>
+<pre><code>@equalityClass class Option[+T] { ... }
+</code></pre>
+<p>then the <code>eqOption</code> definition above would be generated automatically in <code>Option</code>'s companion object.</p>
+<p>Given a set of <code>Eq</code> instances, the idea is that the Scala compiler will check every time it encounters a <em>potentially problematic</em> comparison between values of types <code>T</code> and <code>U</code> that there is an implicit instance of <code>Eq[T, U]</code>. A comparison is <em>potentially problematic</em> if it is between incompatible types. As long as <code>T &lt;: U</code> or <code>U &lt;: T</code> the equality could make sense because both sides can potentially be the same value.</p>
+<p>So this means we still keep universal equality as it is in Scala now - we don't have a choice here anyway, because of backwards compatibility. But we render it safe by checking that for each comparison the corresponding <code>Eq</code> instance exists.</p>
+<p>What about types for which no <code>Eq</code> instance exists? To maintain backwards compatibility, we allow comparisons of such types as well, by means of a fall-back <code>eqAny</code> instance. But we do not allow comparisons between types that have an <code>Eq</code> instance and types that have none.  Details are explained in the <a href="https://github.com/lampepfl/dotty/issues/1247">proposal</a>.</p>
+<h2><a href="#properties" id="properties">Properties</a></h2>
+<p>Here are some nice properties of the proposal</p>
+<ol>
+<li>It is <em>opt-in</em>. To get safe checking, developers have to annotate with <code>@equalityClass</code> classes that should allow comparisons only between their instances, or they have to define implicit <code>Eq</code> instances by hand.  2. It is backwards compatible. Without developer-provided <code>Eq</code> instances, equality works as before.</li>
+<li>It carries no run-time cost compared to universal equality. Indeed the run-time behavior of equality is not affected at all.</li>
+<li>It has no problems with parametricity, variance, or bottom types.  5. Depending on the actual <code>Eq</code> instances given, it can be very precise. That is, no comparisons that might yield <code>true</code> need to be rejected, and most comparisons that will always yield <code>false</code> are in fact rejected.</li>
+</ol>
+<p>The scheme effectively leads to a partition of the former universe of types into sets of types. Values with types in the same partition can be compared among themselves but values with types in different partitions cannot.  An <code>@equalityClass</code> annotation on a type creates a new partition. All types that do not have any <code>Eq</code> instances (except <code>eqAny</code>, that is) form together another partition.  So instead of a single <em>universe</em> of values that can be compared to each other we get a <em>multiverse</em> of partitions. Hence the name of the proposal: <strong>Multiversal Equality</strong>.</p>
diff --git a/blog/2016/12/05/implicit-function-types.html b/blog/2016/12/05/implicit-function-types.html
new file mode 100644
index 000000000..7613d9372
--- /dev/null
+++ b/blog/2016/12/05/implicit-function-types.html
@@ -0,0 +1,308 @@
+<p>I just made the <a href="https://github.com/lampepfl/dotty/pull/1775">first pull request</a> to add <em>implicit function types</em> to
+Scala. I am pretty excited about it, because - citing the explanation
+of the pull request - &quot;<em>This is the first step to bring contextual
+abstraction to Scala</em>&quot;. What do I mean by this?</p>
+<p><strong>Abstraction</strong>: The ability to name a concept and use just the name afterwards.</p>
+<p><strong>Contextual</strong>: A piece of a program produces results or outputs in
+some context. Our programming languages are very good in describing
+and abstracting what outputs are produced. But there's hardly anything
+yet available to abstract over the inputs that programs get from their
+context. Many interesting scenarios fall into that category,
+including:</p>
+<ul>
+<li>passing configuration data to the parts of a system that need them,</li>
+<li>managing capabilities for security critical tasks,</li>
+<li>wiring components up with dependency injection,</li>
+<li>defining the meanings of operations with type classes,</li>
+<li>more generally, passing any sort of context to a computation.</li>
+</ul>
+<p>Implicit function types are a surprisingly simple and general way to
+make coding patterns solving these tasks abstractable, reducing
+boilerplate code and increasing applicability.</p>
+<p><strong>First Step</strong>: My pull request is a first implementation. It solves the
+problem in principle, but introduces some run-time overhead. The
+next step will be to eliminate the run-time overhead through some
+simple optimizations.</p>
+<h2><a href="#implicit-parameters" id="implicit-parameters">Implicit Parameters</a></h2>
+<p>In a functional setting, the inputs to a computation are most
+naturally expressed as <em>parameters</em>. One could simply augment
+functions to take additional parameters that represent configurations,
+capabilities, dictionaries, or whatever contextual data the functions
+need. The only downside with this is that often there's a large
+distance in the call graph between the definition of a contextual
+element and the site where it is used. Consequently, it becomes
+tedious to define all those intermediate parameters and to pass them
+along to where they are eventually consumed.</p>
+<p>Implicit parameters solve one half of the problem. Implicit
+parameters do not have to be propagated using boilerplate code; the
+compiler takes care of that. This makes them practical in many
+scenarios where plain parameters would be too cumbersome. For
+instance, type classes would be a lot less popular if one would have
+to pass all dictionaries by hand. Implicit parameters are also very
+useful as a general context passing mechanism. For instance in the
+<em>dotty</em> compiler, almost every function takes an implicit context
+parameter which defines all elements relating to the current state of
+the compilation. This is in my experience much better than the cake
+pattern because it is lightweight and can express context changes in a
+purely functional way.</p>
+<p>The main downside of implicit parameters is the verbosity of their
+declaration syntax. It's hard to illustrate this with a smallish example,
+because it really only becomes a problem at scale, but let's try anyway.</p>
+<p>Let's say we want to write some piece of code that's designed to run
+in a transaction. For the sake of illustration here's a simple transaction class:</p>
+<pre><code>class Transaction {
+  private val log = new ListBuffer[String]
+  def println(s: String): Unit = log += s
+
+  private var aborted = false
+  private var committed = false
+
+  def abort(): Unit = { aborted = true }
+  def isAborted = aborted
+
+  def commit(): Unit =
+    if (!aborted &amp;&amp; !committed) {
+      Console.println(&quot;******* log ********&quot;)
+      log.foreach(Console.println)
+      committed = true
+    }
+}
+</code></pre>
+<p>The transaction encapsulates a log, to which one can print messages.
+It can be in one of three states: running, committed, or aborted.
+If the transaction is committed, it prints the stored log to the console.</p>
+<p>The <code>transaction</code> method lets one run some given code <code>op</code> inside
+a newly created transaction:</p>
+<pre><code>  def transaction[T](op: Transaction =&gt; T) = {
+    val trans: Transaction = new Transaction
+    op(trans)
+    trans.commit()
+  }
+</code></pre>
+<p>The current transaction needs to be passed along a call chain to all
+the places that need to access it. To illustrate this, here are three
+functions <code>f1</code>, <code>f2</code> and <code>f3</code> which call each other, and also access
+the current transaction. The most convenient way to achieve this is
+by passing the current transaction as an implicit parameter.</p>
+<pre><code>  def f1(x: Int)(implicit thisTransaction: Transaction): Int = {
+    thisTransaction.println(s&quot;first step: $x&quot;)
+    f2(x + 1)
+  }
+  def f2(x: Int)(implicit thisTransaction: Transaction): Int = {
+    thisTransaction.println(s&quot;second step: $x&quot;)
+    f3(x * x)
+  }
+  def f3(x: Int)(implicit thisTransaction: Transaction): Int = {
+    thisTransaction.println(s&quot;third step: $x&quot;)
+    if (x % 2 != 0) thisTransaction.abort()
+    x
+  }
+</code></pre>
+<p>The main program calls <code>f1</code> in a fresh transaction context and prints
+its result:</p>
+<pre><code>  def main(args: Array[String]) = {
+    transaction {
+      implicit thisTransaction =&gt;
+        val res = f1(args.length)
+        println(if (thisTransaction.isAborted) &quot;aborted&quot; else s&quot;result: $res&quot;)
+    }
+  }
+</code></pre>
+<p>Two sample calls of the program (let's call it <code>TransactionDemo</code>) are here:</p>
+<pre><code>scala TransactionDemo 1 2 3
+result: 16
+******* log ********
+first step: 3
+second step: 4
+third step: 16
+
+scala TransactionDemo 1 2 3 4
+aborted
+</code></pre>
+<p>So far, so good. The code above is quite compact as far as expressions
+are concerned. In particular, it's nice that, being implicit
+parameters, none of the transaction values had to be passed along
+explicitly in a call. But on the definition side, things are less
+rosy: Every one of the functions <code>f1</code> to <code>f3</code> needed an additional
+implicit parameter:</p>
+<pre><code>(implicit thisTransaction: Transaction)
+</code></pre>
+<p>A three-times repetition might not look so bad here, but it certainly
+smells of boilerplate. In real-sized projects, this can get much worse.
+For instance, the <em>dotty</em> compiler uses implicit abstraction
+over contexts for most of its parts. Consequently it ends up with currently
+no fewer than 2641 occurrences of the text string</p>
+<pre><code>(implicit ctx: Context)
+</code></pre>
+<p>It would be nice if we could get rid of them.</p>
+<h2><a href="#implicit-functions" id="implicit-functions">Implicit Functions</a></h2>
+<p>Let's massage the definition of <code>f1</code> a bit by moving the last parameter section to the right of the equals sign:</p>
+<pre><code>  def f1(x: Int) = { implicit thisTransaction: Transaction =&gt;
+    thisTransaction.println(s&quot;first step: $x&quot;)
+    f2(x + 1)
+  }
+</code></pre>
+<p>The right hand side of this new version of <code>f1</code> is now an implicit
+function value. What's the type of this value? Previously, it was
+<code>Transaction =&gt; Int</code>, that is, the knowledge that the function has an
+implicit parameter got lost in the type. The main extension implemented by
+the pull request is to introduce implicit function types that mirror
+the implicit function values which we have already. Concretely, the new
+type of <code>f1</code> is:</p>
+<pre><code>implicit Transaction =&gt; Int
+</code></pre>
+<p>Just like the normal function type syntax <code>A =&gt; B</code>, desugars to <code>scala.Function1[A, B]</code>
+the implicit function type syntax <code>implicit A =&gt; B</code> desugars to <code>scala.ImplicitFunction1[A, B]</code>.
+The same holds at other function arities. With dotty's <a href="https://github.com/lampepfl/dotty/pull/1758">pull request #1758</a>
+merged there is no longer an upper limit of 22 for such functions.</p>
+<p>The type <code>ImplicitFunction1</code> can be thought of being defined as follows:</p>
+<pre><code>trait ImplicitFunction1[-T0, R] extends Function1[T0, R] {
+  override def apply(implicit x: T0): R
+}
+</code></pre>
+<p>However, you won't find a classfile for this trait because all implicit function traits
+get mapped to normal functions during type erasure.</p>
+<p>There are two rules that guide type checking of implicit function types.
+The first rule says that an implicit function is applied to implicit arguments
+in the same way an implicit method is. More precisely, if <code>t</code> is an expression
+of an implicit function type</p>
+<pre><code>t: implicit (T1, ..., Tn) =&gt; R
+</code></pre>
+<p>such that <code>t</code> is not an implicit closure itself and <code>t</code> is not the
+prefix of a call <code>t.apply(...)</code>, then an <code>apply</code> is implicitly
+inserted, so <code>t</code> becomes <code>t.apply</code>. We have already seen that the
+definition of <code>t.apply</code> is an implicit method as given in the
+corresponding implicit function trait. Hence, it will in turn be
+applied to a matching sequence of implicit arguments. The end effect is
+that references to implicit functions get applied to implicit arguments in the
+same way as references to implicit methods.</p>
+<p>The second rule is the dual of the first. If the expected type
+of an expression <code>t</code> is an implicit function type</p>
+<pre><code>implicit (T1, ..., Tn) =&gt; R
+</code></pre>
+<p>then <code>t</code> is converted to an implicit closure, unless it is already one.
+More precisely, <code>t</code> is mapped to the implicit closure</p>
+<pre><code>implicit ($ev1: T1, ..., $evn: Tn) =&gt; t
+</code></pre>
+<p>The parameter names of this closure are compiler-generated identifiers
+which should not be accessed from user code. That is, the only way to
+refer to an implicit parameter of a compiler-generated function is via
+<code>implicitly</code>.</p>
+<p>It is important to note that this second conversion needs to be applied
+<em>before</em> the expression <code>t</code> is typechecked. This is because the
+conversion establishes the necessary context to make type checking <code>t</code>
+succeed by defining the required implicit parameters.</p>
+<p>There is one final tweak to make this all work: When using implicit parameters
+for nested functions it was so far important to give all implicit parameters
+of the same type the same name, or else one would get ambiguities. For instance, consider the
+following fragment:</p>
+<pre><code>def f(implicit c: C) = {
+  def g(implicit c: C) = ... implicitly[C] ...
+  ...
+}
+</code></pre>
+<p>If we had named the inner parameter <code>d</code> instead of <code>c</code> we would
+have gotten an implicit ambiguity at the call of <code>implicitly</code> because
+both <code>c</code> and <code>d</code> would be eligible:</p>
+<pre><code>def f(implicit c: C) = {
+  def g(implicit d: C) = ... implicitly[C] ... // error!
+  ...
+}
+</code></pre>
+<p>The problem is that parameters in implicit closures now have
+compiler-generated names, so the programmer cannot enforce the proper
+naming scheme to avoid all ambiguities. We fix the problem by
+introducing a new disambiguation rule which makes nested occurrences
+of an implicit take precedence over outer ones. This rule, which
+applies to all implicit parameters and implicit locals, is conceptually
+analogous to the rule that prefers implicits defined in companion
+objects of subclasses over those defined in companion objects of
+superclass. With that new disambiguation rule the example code above
+now compiles.</p>
+<p>That's the complete set of rules needed to deal with implicit function types.</p>
+<h2><a href="#how-to-remove-boilerplate" id="how-to-remove-boilerplate">How to Remove Boilerplate</a></h2>
+<p>The main advantage of implicit function types is that, being types,
+they can be abstracted. That is, one can define a name for an implicit
+function type and then use just the name instead of the full type.
+Let's revisit our previous example and see how it can be made more
+concise using this technique.</p>
+<p>We first define a type <code>Transactional</code> for functions that take an implicit parameter of type <code>Transaction</code>:</p>
+<pre><code>type Transactional[T] = implicit Transaction =&gt; T
+</code></pre>
+<p>Making the return type of <code>f1</code> to <code>f3</code> a <code>Transactional[Int]</code>, we can
+eliminate their implicit parameter sections:</p>
+<pre><code>  def f1(x: Int): Transactional[Int] = {
+    thisTransaction.println(s&quot;first step: $x&quot;)
+    f2(x + 1)
+  }
+  def f2(x: Int): Transactional[Int] = {
+    thisTransaction.println(s&quot;second step: $x&quot;)
+    f3(x * x)
+  }
+  def f3(x: Int): Transactional[Int] = {
+    thisTransaction.println(s&quot;third step: $x&quot;)
+    if (x % 2 != 0) thisTransaction.abort()
+    x
+  }
+</code></pre>
+<p>You might ask, how does <code>thisTransaction</code> typecheck, since there is no
+longer a parameter with that name? In fact, <code>thisTransaction</code> is now a
+global definition:</p>
+<pre><code>  def thisTransaction: Transactional[Transaction] = implicitly[Transaction]
+</code></pre>
+<p>You might ask: a <code>Transactional[Transaction]</code>, is that not circular? To see more clearly, let's expand
+the definition according to the rules given in the last section. <code>thisTransaction</code>
+is of implicit function type, so the right hand side is expanded to the
+implicit closure</p>
+<pre><code>  implicit ($ev0: Transaction) =&gt; implicitly[Transaction]
+</code></pre>
+<p>The right hand side of this closure, <code>implicitly[Transaction]</code>, needs
+an implicit parameter of type <code>Transaction</code>, so the closure is further
+expanded to</p>
+<pre><code>  implicit ($ev0: Transaction) =&gt; implicitly[Transaction]($ev0)
+</code></pre>
+<p>Now, <code>implicitly</code> is defined in <code>scala.Predef</code> like this:</p>
+<pre><code>  def implicitly[T](implicit x: T) = x
+</code></pre>
+<p>If we plug that definition into the closure above and simplify, we get:</p>
+<pre><code>  implicit ($ev0: Transaction) =&gt; $ev0
+</code></pre>
+<p>So, <code>thisTransaction</code> is just the implicit identity function on <code>transaction</code>!
+In other words, if we use <code>thisTransaction</code> in the body of <code>f1</code> to <code>f3</code>, it will
+pick up and return the unnamed implicit parameter that's in scope.</p>
+<p>Finally, here are the <code>transaction</code> and <code>main</code> method that complete
+the example.  Since <code>transactional</code>'s parameter <code>op</code> is now a
+<code>Transactional</code>, we can eliminate the <code>Transaction</code> argument to <code>op</code>
+and the <code>Transaction</code> lambda in <code>main</code>; both will be added by the compiler.</p>
+<pre><code>  def transaction[T](op: Transactional[T]) = {
+    implicit val trans: Transaction = new Transaction
+    op
+    trans.commit()
+  }
+  def main(args: Array[String]) = {
+    transaction {
+      val res = f1(args.length)
+      println(if (thisTransaction.isAborted) &quot;aborted&quot; else s&quot;result: $res&quot;)
+    }
+  }
+</code></pre>
+<h2><a href="#categorically-speaking" id="categorically-speaking">Categorically Speaking</a></h2>
+<p>There are many interesting connections with category theory to explore
+here. On the one hand, implicit functions are used for tasks that are
+sometimes covered with monads such as the reader monad. There's an
+argument to be made that implicits have better composability than
+monads and why that is.</p>
+<p>On the other hand, it turns out that implicit functions can also be
+given a co-monadic interpretation, and the interplay between monads and
+comonads is very interesting in its own right.</p>
+<p>But these discussions will have to wait for another time, as
+this blog post is already too long.</p>
+<h2><a href="#conclusion" id="conclusion">Conclusion</a></h2>
+<p>Implicit function types are unique way to abstract over the context in
+which some piece of code is run. I believe they will deeply influence
+the way we write Scala in the future. They are very powerful
+abstractions, in the sense that just declaring a type of a function
+will inject certain implicit values into the scope of the function's
+implementation. Can this be abused, making code more obscure?
+Absolutely, like every other powerful abstraction technique. To keep
+your code sane, please keep the <a href="http://www.lihaoyi.com/post/StrategicScalaStylePrincipleofLeastPower.html">Principle of Least Power</a> in mind.</p>
diff --git a/blog/index.html b/blog/index.html
new file mode 100644
index 000000000..9e124d85f
--- /dev/null
+++ b/blog/index.html
@@ -0,0 +1,282 @@
+<!DOCTYPE html>
+<html lang="en">
+    <head>
+        <meta charset="utf-8">
+        <meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">
+        <meta http-equiv="x-ua-compatible" content="ie=edge">
+
+        <title>Blog</title>
+
+        <link
+            rel="stylesheet"
+            href="https://maxcdn.bootstrapcdn.com/bootstrap/4.0.0-alpha.5/css/bootstrap.min.css"
+            integrity="sha384-AysaV+vQoT3kOAXZkl02PThvDr8HYKPZhNT5h/CXfBThSRXQ6jW5DO2ekP5ViFdi"
+            crossorigin="anonymous"
+        >
+        <link
+            rel="stylesheet"
+            href="https://maxcdn.bootstrapcdn.com/font-awesome/4.5.0/css/font-awesome.min.css"
+        >
+
+        <link href="https://fonts.googleapis.com/icon?family=Material+Icons" rel="stylesheet">
+
+        <link
+            rel="stylesheet"
+            href=".././css/dottydoc.css"
+        >
+
+        <link
+            rel="stylesheet"
+            href=".././css/color-brewer.css"
+        >
+
+        
+    </head>
+    <body>
+
+        
+<div id="content-wrapper">
+    <div class="index-wrapper">
+        <ul class="toc">
+    <li class="logo-li">
+        <a id="home-button" href=".././index.html">
+            <svg width="64px" height="109px" viewBox="0 0 64 109" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
+    <g id="Page-1" stroke="none" stroke-width="1" fill="none" fill-rule="evenodd">
+        <g id="logo-background" transform="translate(0.000000, 16.000000)" fill="#636363">
+            <path d="M0.5,59.5 C0.5,59.5 63.4,65.8 63.4,76.3 L63.4,51.1 C63.4,51.1 63.4,40.6 0.5,34.3 L0.5,59.5 L0.5,59.5 Z" id="logo-background-bottom"></path>
+            <path d="M0.5,25.9 C0.5,25.9 63.4,32.2 63.4,42.7 L63.4,17.5 C63.4,17.5 63.4,7 0.5,0.7 L0.5,10.5 L0.5,25.9 L0.5,25.9 Z" id="logo-background-top"></path>
+        </g>
+        <g id="logo-foreground" fill="#B6B6B6">
+            <path d="M0.5,109 L0.5,83.8 C0.5,83.8 63.4,77.5 63.4,67 L63.4,92.2 C63.5,92.3 63.5,102.7 0.5,109" id="Logo_Foreground_Bottom"></path>
+            <path d="M0.5,50.3 C0.5,50.3 63.4,44 63.4,33.5 L63.4,58.7 C63.4,58.7 63.4,69.2 0.5,75.5 L0.5,50.3 L0.5,50.3 Z" id="Logo_Foreground_Middle"></path>
+            <path d="M63.5,0 L63.5,25.2 C63.5,25.2 63.5,35.7 0.6,42 L0.6,16.7 C0.5,16.7 63.5,10.5 63.5,0" id="logo-foreground-top"></path>
+        </g>
+        <g id="dots" transform="translate(4.000000, 10.000000)" fill="#FFFFFF">
+            <g id="bottom" transform="translate(0.000000, 67.500000)">
+                <path d="M1.4471104,12.2885536 C1.45019313,12.2881864 1.45019313,12.2881864 1.45327704,12.2878189 C1.91768952,12.2324787 2.24930811,11.8111359 2.1939679,11.3467234 C2.13862768,10.8823109 1.71728488,10.5506923 1.2528724,10.6060325 C1.24980572,10.606398 1.24980572,10.606398 1.24674021,10.6067632 C0.782326598,10.6620939 0.450699376,11.0834299 0.506030077,11.5478435 C0.561360778,12.0122571 0.982696791,12.3438844 1.4471104,12.2885536 L1.4471104,12.2885536 Z M9.34858965,12.1304907 C9.35409106,12.129756 9.35409106,12.129756 9.35959333,12.129021 C10.1807278,12.019341 10.7574756,11.2647668 10.6477955,10.4436323 C10.5381155,9.62249789 9.78354128,9.04575011 8.96240683,9.15543014 C8.95693539,9.15616095 8.95693539,9.15616095 8.95146479,9.15689157 C8.13032806,9.26655457 7.55356464,10.0211168 7.66322765,10.8422536 C7.77289065,11.6633903 8.52745292,12.2401537 9.34858965,12.1304907 L9.34858965,12.1304907 Z M17.0066591,11.0493128 C17.0121188,11.0484984 17.0121188,11.0484984 17.0175789,11.0476838 C17.8369369,10.9254384 18.4020584,10.1621181 18.279813,9.34276003 C18.1575677,8.52340201 17.3942473,7.95828052 16.5748893,8.08052587 C16.5694641,8.08133528 16.5694641,8.08133528 16.5640392,8.08214454 C15.7446783,8.20437064 15.1795389,8.96767771 15.301765,9.78703861 C15.4239911,10.6063995 16.1872982,11.1715389 17.0066591,11.0493128 L17.0066591,11.0493128 Z M24.8225082,10.4232459 C24.8297684,10.4220275 24.8297684,10.4220275 24.8370287,10.420809 C25.922252,10.2386672 26.6543441,9.21126476 26.4722023,8.12604147 C26.2900605,7.04081818 25.2626581,6.30872601 24.1774348,6.49086783 C24.1702314,6.4920768 24.1702314,6.4920768 24.1630282,6.49328559 C23.0777996,6.67539597 22.3456777,7.70277717 22.5277881,8.78800574 C22.7098984,9.87323431 23.7372796,10.6053563 24.8225082,10.4232459 L24.8225082,10.4232459 Z M32.4725265,9.05261002 C33.5532108,8.84532993 34.2612448,7.80122849 34.0539647,6.72054419 C33.8466846,5.63985989 32.8025831,4.93182589 31.7218988,5.13910599 C31.714724,5.14048211 31.714724,5.14048211 31.7075489,5.14185807 C30.6268567,5.34909665 29.9187826,6.39317088 30.1260211,7.47386314 C30.3332597,8.5545554 31.3773339,9.26262952 32.4580262,9.05539095 C32.4652764,9.05400057 32.4652764,9.05400057 32.4725265,9.05261002 Z M39.8723866,6.89476879 C39.877909,6.8935242 39.877909,6.8935242 39.883431,6.89227947 C40.6915794,6.71010471 41.1990314,5.90728916 41.0168566,5.09914075 C40.8346818,4.29099233 40.0318663,3.78354042 39.2237179,3.96571517 C39.218279,3.96694116 39.218279,3.96694116 39.2128397,3.96816703 C38.404681,4.15029588 37.8971834,4.9530826 38.0793123,5.76124136 C38.2614411,6.56940012 39.0642279,7.07689764 39.8723866,6.89476879 L39.8723866,6.89476879 Z M47.4276119,5.00828445 C47.4329844,5.00678549 47.4329844,5.00678549 47.4383562,5.00528637 C48.2362896,4.78258973 48.7026111,3.95520561 48.4799145,3.15727221 C48.2572179,2.35933881 47.4298337,1.89301728 46.6319003,2.11571391 C46.6266645,2.1171751 46.6266645,2.1171751 46.6214279,2.11863616 C45.8234736,2.34125773 45.3570742,3.16859798 45.5796958,3.96655233 C45.8023173,4.76450667 46.6296576,5.23090603 47.4276119,5.00828445 L47.4276119,5.00828445 Z M54.419759,2.30643871 C54.8556933,2.13695884 55.0716973,1.6461737 54.9022174,1.21023941 C54.7327376,0.774305114 54.2419524,0.558301127 53.8060181,0.727780997 C53.8032127,0.728871549 53.8032127,0.728871549 53.8004064,0.729962021 C53.3644359,0.89934874 53.148327,1.39008772 53.3177137,1.82605822 C53.4871005,2.26202871 53.9778394,2.47813756 54.4138099,2.30875084 C54.4167849,2.30759485 54.4167849,2.30759485 54.419759,2.30643871 Z" id="Shape"></path>
+                <path d="M1.67760355,20.096503 C1.68306395,20.0958524 1.68306395,20.0958524 1.68852642,20.0952015 C2.51113381,19.9971782 3.09852524,19.2508595 3.00050189,18.4282521 C2.90247854,17.6056447 2.15615986,17.0182533 1.33355246,17.1162767 C1.3281205,17.1169239 1.3281205,17.1169239 1.3226906,17.1175709 C0.500081196,17.2155774 -0.0873255124,17.961884 0.0106809923,18.7844934 C0.108687497,19.6071028 0.854994145,20.1945095 1.67760355,20.096503 L1.67760355,20.096503 Z M9.34858965,19.1274206 C9.35409106,19.1266859 9.35409106,19.1266859 9.35959333,19.1259509 C10.1807278,19.0162709 10.7574756,18.2616967 10.6477955,17.4405622 C10.5381155,16.6194278 9.78354128,16.04268 8.96240683,16.15236 C8.95693539,16.1530908 8.95693539,16.1530908 8.95146479,16.1538215 C8.13032806,16.2634845 7.55356464,17.0180467 7.66322765,17.8391835 C7.77289065,18.6603202 8.52745292,19.2370836 9.34858965,19.1274206 L9.34858965,19.1274206 Z M17.1767435,18.6256231 C17.1839958,18.6245412 17.1839958,18.6245412 17.1912486,18.6234592 C18.27963,18.4610765 19.0303002,17.4471319 18.8679175,16.3587506 C18.7055348,15.2703693 17.6915903,14.519699 16.6032089,14.6820817 C16.5960024,14.6831569 16.5960024,14.6831569 16.5887964,14.6842319 C15.5004112,14.846589 14.7497172,15.8605159 14.9120743,16.948901 C15.0744314,18.0372862 16.0883584,18.7879802 17.1767435,18.6256231 L17.1767435,18.6256231 Z M24.8370287,17.4177379 C25.922252,17.2355961 26.6543441,16.2081937 26.4722023,15.1229704 C26.2900605,14.0377471 25.2626581,13.3056549 24.1774348,13.4877968 C24.1702314,13.4890057 24.1702314,13.4890057 24.1630282,13.4902145 C23.0777996,13.6723249 22.3456777,14.6997061 22.5277881,15.7849347 C22.7098984,16.8701632 23.7372796,17.6022852 24.8225082,17.4201748 C24.8297684,17.4189565 24.8297684,17.4189565 24.8370287,17.4177379 Z M32.4725265,16.061085 C33.5532108,15.853199 34.2612448,14.8060455 34.0539647,13.7222022 C33.8466846,12.6383589 32.8025831,11.9282552 31.7218988,12.1361412 C31.714724,12.1375214 31.714724,12.1375214 31.7075489,12.1389013 C30.6268567,12.3467457 29.9187826,13.3938719 30.1260211,14.4777232 C30.3332597,15.5615745 31.3773339,16.2717185 32.4580262,16.0638741 C32.4652764,16.0624797 32.4652764,16.0624797 32.4725265,16.061085 Z M40.0707225,14.4695476 C40.0780573,14.4678946 40.0780573,14.4678946 40.0853916,14.4662413 C41.158768,14.2242783 41.8327617,13.1579849 41.5907986,12.0846085 C41.3488355,11.011232 40.2825422,10.3372384 39.2091657,10.5792015 C39.2019419,10.5808298 39.2019419,10.5808298 39.1947175,10.582458 C38.1213273,10.8243601 37.447273,11.8906152 37.6891752,12.9640053 C37.9310773,14.0373955 38.9973324,14.7114498 40.0707225,14.4695476 L40.0707225,14.4695476 Z M47.4276119,12.0082845 C47.4329844,12.0067855 47.4329844,12.0067855 47.4383562,12.0052864 C48.2362896,11.7825897 48.7026111,10.9552056 48.4799145,10.1572722 C48.2572179,9.35933881 47.4298337,8.89301728 46.6319003,9.11571391 C46.6266645,9.1171751 46.6266645,9.1171751 46.6214279,9.11863616 C45.8234736,9.34125773 45.3570742,10.168598 45.5796958,10.9665523 C45.8023173,11.7645067 46.6296576,12.230906 47.4276119,12.0082845 L47.4276119,12.0082845 Z M54.8999721,9.57562965 C54.9052414,9.57358217 54.9052414,9.57358217 54.9105092,9.57153441 C55.6826371,9.27135123 56.0652239,8.40207131 55.7650408,7.62994336 C55.4648576,6.85781542 54.5955777,6.4752286 53.8234497,6.77541179 C53.8184808,6.77734338 53.8184808,6.77734338 53.8135101,6.77927482 C53.0413181,7.07929302 52.6585455,7.94849117 52.9585637,8.72068323 C53.2585819,9.4928753 54.12778,9.87564785 54.8999721,9.57562965 L54.8999721,9.57562965 Z" id="Shape"></path>
+                <path d="M1.45327704,26.6978168 C1.54647464,26.6867112 1.63432439,26.660866 1.7147722,26.6228911 C2.03520341,26.4716332 2.23820252,26.1279362 2.1939679,25.7567213 C2.13862768,25.2923089 1.71728488,24.9606903 1.2528724,25.0160305 C1.24980572,25.0163959 1.24980572,25.0163959 1.24674021,25.0167611 C0.782326598,25.0720918 0.450699376,25.4934278 0.506030077,25.9578415 C0.561360778,26.4222551 0.982696791,26.7538823 1.4471104,26.6985516 C1.45019313,26.6981843 1.45019313,26.6981843 1.45327704,26.6978168 Z M9.34858965,26.1274206 C9.35409106,26.1266859 9.35409106,26.1266859 9.35959333,26.1259509 C10.1807278,26.0162709 10.7574756,25.2616967 10.6477955,24.4405622 C10.5381155,23.6194278 9.78354128,23.04268 8.96240683,23.15236 C8.95693539,23.1530908 8.95693539,23.1530908 8.95146479,23.1538215 C8.13032806,23.2634845 7.55356464,24.0180467 7.66322765,24.8391835 C7.77289065,25.6603202 8.52745292,26.2370836 9.34858965,26.1274206 L9.34858965,26.1274206 Z M17.0066591,25.0462427 C17.0121188,25.0454283 17.0121188,25.0454283 17.0175789,25.0446136 C17.8369369,24.9223683 18.4020584,24.1590479 18.279813,23.3396899 C18.1575677,22.5203319 17.3942473,21.9552104 16.5748893,22.0774558 C16.5694641,22.0782652 16.5694641,22.0782652 16.5640392,22.0790744 C15.7446783,22.2013005 15.1795389,22.9646076 15.301765,23.7839685 C15.4239911,24.6033294 16.1872982,25.1684688 17.0066591,25.0462427 L17.0066591,25.0462427 Z M24.8225082,24.4201748 C24.8297684,24.4189565 24.8297684,24.4189565 24.8370287,24.4177379 C25.922252,24.2355961 26.6543441,23.2081937 26.4722023,22.1229704 C26.2900605,21.0377471 25.2626581,20.3056549 24.1774348,20.4877968 C24.1702314,20.4890057 24.1702314,20.4890057 24.1630282,20.4902145 C23.0777996,20.6723249 22.3456777,21.6997061 22.5277881,22.7849347 C22.7098984,23.8701632 23.7372796,24.6022852 24.8225082,24.4201748 L24.8225082,24.4201748 Z M32.4725265,23.0495399 C33.5532108,22.8422598 34.2612448,21.7981584 34.0539647,20.7174741 C33.8466846,19.6367898 32.8025831,18.9287558 31.7218988,19.1360359 C31.714724,19.137412 31.714724,19.137412 31.7075489,19.138788 C30.6268567,19.3460265 29.9187826,20.3901008 30.1260211,21.470793 C30.3332597,22.5514853 31.3773339,23.2595594 32.4580262,23.0523208 C32.4652764,23.0509305 32.4652764,23.0509305 32.4725265,23.0495399 Z M39.8723866,20.8947688 C39.877909,20.8935242 39.877909,20.8935242 39.883431,20.8922795 C40.6915794,20.7101047 41.1990314,19.9072892 41.0168566,19.0991407 C40.8346818,18.2909923 40.0318663,17.7835404 39.2237179,17.9657152 C39.218279,17.9669412 39.218279,17.9669412 39.2128397,17.968167 C38.404681,18.1502959 37.8971834,18.9530826 38.0793123,19.7612414 C38.2614411,20.5694001 39.0642279,21.0768976 39.8723866,20.8947688 L39.8723866,20.8947688 Z M47.4276119,19.0082845 C47.4329844,19.0067855 47.4329844,19.0067855 47.4383562,19.0052864 C48.2362896,18.7825897 48.7026111,17.9552056 48.4799145,17.1572722 C48.2572179,16.3593388 47.4298337,15.8930173 46.6319003,16.1157139 C46.6266645,16.1171751 46.6266645,16.1171751 46.6214279,16.1186362 C45.8234736,16.3412577 45.3570742,17.168598 45.5796958,17.9665523 C45.8023173,18.7645067 46.6296576,19.230906 47.4276119,19.0082845 L47.4276119,19.0082845 Z M54.4138099,15.7087505 C54.4167849,15.7075945 54.4167849,15.7075945 54.419759,15.7064383 C54.8556933,15.5369585 55.0716973,15.0461733 54.9022174,14.610239 C54.7327376,14.1743047 54.2419524,13.9583007 53.8060181,14.1277806 C53.8032127,14.1288712 53.8032127,14.1288712 53.8004064,14.1299616 C53.3644359,14.2993484 53.148327,14.7900873 53.3177137,15.2260578 C53.4871005,15.6620283 53.9778394,15.8781372 54.4138099,15.7087505 L54.4138099,15.7087505 Z" id="Shape"></path>
+            </g>
+            <g id="middle" transform="translate(0.000000, 33.900002)">
+                <path d="M1.4471104,12.2885536 C1.45019313,12.2881864 1.45019313,12.2881864 1.45327704,12.2878189 C1.91768952,12.2324787 2.24930811,11.8111359 2.1939679,11.3467234 C2.13862768,10.8823109 1.71728488,10.5506923 1.2528724,10.6060325 C1.24980572,10.606398 1.24980572,10.606398 1.24674021,10.6067632 C0.782326598,10.6620939 0.450699376,11.0834299 0.506030077,11.5478435 C0.561360778,12.0122571 0.982696791,12.3438844 1.4471104,12.2885536 L1.4471104,12.2885536 Z M9.34858965,12.1304907 C9.35409106,12.129756 9.35409106,12.129756 9.35959333,12.129021 C10.1807278,12.019341 10.7574756,11.2647668 10.6477955,10.4436323 C10.5381155,9.62249789 9.78354128,9.04575011 8.96240683,9.15543014 C8.95693539,9.15616095 8.95693539,9.15616095 8.95146479,9.15689157 C8.13032806,9.26655457 7.55356464,10.0211168 7.66322765,10.8422536 C7.77289065,11.6633903 8.52745292,12.2401537 9.34858965,12.1304907 L9.34858965,12.1304907 Z M17.0066591,11.0493128 C17.0121188,11.0484984 17.0121188,11.0484984 17.0175789,11.0476838 C17.8369369,10.9254384 18.4020584,10.1621181 18.279813,9.34276003 C18.1575677,8.52340201 17.3942473,7.95828052 16.5748893,8.08052587 C16.5694641,8.08133528 16.5694641,8.08133528 16.5640392,8.08214454 C15.7446783,8.20437064 15.1795389,8.96767771 15.301765,9.78703861 C15.4239911,10.6063995 16.1872982,11.1715389 17.0066591,11.0493128 L17.0066591,11.0493128 Z M24.8225082,10.4232459 C24.8297684,10.4220275 24.8297684,10.4220275 24.8370287,10.420809 C25.922252,10.2386672 26.6543441,9.21126476 26.4722023,8.12604147 C26.2900605,7.04081818 25.2626581,6.30872601 24.1774348,6.49086783 C24.1702314,6.4920768 24.1702314,6.4920768 24.1630282,6.49328559 C23.0777996,6.67539597 22.3456777,7.70277717 22.5277881,8.78800574 C22.7098984,9.87323431 23.7372796,10.6053563 24.8225082,10.4232459 L24.8225082,10.4232459 Z M32.4725265,9.05261002 C33.5532108,8.84532993 34.2612448,7.80122849 34.0539647,6.72054419 C33.8466846,5.63985989 32.8025831,4.93182589 31.7218988,5.13910599 C31.714724,5.14048211 31.714724,5.14048211 31.7075489,5.14185807 C30.6268567,5.34909665 29.9187826,6.39317088 30.1260211,7.47386314 C30.3332597,8.5545554 31.3773339,9.26262952 32.4580262,9.05539095 C32.4652764,9.05400057 32.4652764,9.05400057 32.4725265,9.05261002 Z M39.8723866,6.89476879 C39.877909,6.8935242 39.877909,6.8935242 39.883431,6.89227947 C40.6915794,6.71010471 41.1990314,5.90728916 41.0168566,5.09914075 C40.8346818,4.29099233 40.0318663,3.78354042 39.2237179,3.96571517 C39.218279,3.96694116 39.218279,3.96694116 39.2128397,3.96816703 C38.404681,4.15029588 37.8971834,4.9530826 38.0793123,5.76124136 C38.2614411,6.56940012 39.0642279,7.07689764 39.8723866,6.89476879 L39.8723866,6.89476879 Z M47.4276119,5.00828445 C47.4329844,5.00678549 47.4329844,5.00678549 47.4383562,5.00528637 C48.2362896,4.78258973 48.7026111,3.95520561 48.4799145,3.15727221 C48.2572179,2.35933881 47.4298337,1.89301728 46.6319003,2.11571391 C46.6266645,2.1171751 46.6266645,2.1171751 46.6214279,2.11863616 C45.8234736,2.34125773 45.3570742,3.16859798 45.5796958,3.96655233 C45.8023173,4.76450667 46.6296576,5.23090603 47.4276119,5.00828445 L47.4276119,5.00828445 Z M54.419759,2.30643871 C54.8556933,2.13695884 55.0716973,1.6461737 54.9022174,1.21023941 C54.7327376,0.774305114 54.2419524,0.558301127 53.8060181,0.727780997 C53.8032127,0.728871549 53.8032127,0.728871549 53.8004064,0.729962021 C53.3644359,0.89934874 53.148327,1.39008772 53.3177137,1.82605822 C53.4871005,2.26202871 53.9778394,2.47813756 54.4138099,2.30875084 C54.4167849,2.30759485 54.4167849,2.30759485 54.419759,2.30643871 Z" id="Shape"></path>
+                <path d="M1.67760355,20.096503 C1.68306395,20.0958524 1.68306395,20.0958524 1.68852642,20.0952015 C2.51113381,19.9971782 3.09852524,19.2508595 3.00050189,18.4282521 C2.90247854,17.6056447 2.15615986,17.0182533 1.33355246,17.1162767 C1.3281205,17.1169239 1.3281205,17.1169239 1.3226906,17.1175709 C0.500081196,17.2155774 -0.0873255124,17.961884 0.0106809923,18.7844934 C0.108687497,19.6071028 0.854994145,20.1945095 1.67760355,20.096503 L1.67760355,20.096503 Z M9.34858965,19.1274206 C9.35409106,19.1266859 9.35409106,19.1266859 9.35959333,19.1259509 C10.1807278,19.0162709 10.7574756,18.2616967 10.6477955,17.4405622 C10.5381155,16.6194278 9.78354128,16.04268 8.96240683,16.15236 C8.95693539,16.1530908 8.95693539,16.1530908 8.95146479,16.1538215 C8.13032806,16.2634845 7.55356464,17.0180467 7.66322765,17.8391835 C7.77289065,18.6603202 8.52745292,19.2370836 9.34858965,19.1274206 L9.34858965,19.1274206 Z M17.1767435,18.6256231 C17.1839958,18.6245412 17.1839958,18.6245412 17.1912486,18.6234592 C18.27963,18.4610765 19.0303002,17.4471319 18.8679175,16.3587506 C18.7055348,15.2703693 17.6915903,14.519699 16.6032089,14.6820817 C16.5960024,14.6831569 16.5960024,14.6831569 16.5887964,14.6842319 C15.5004112,14.846589 14.7497172,15.8605159 14.9120743,16.948901 C15.0744314,18.0372862 16.0883584,18.7879802 17.1767435,18.6256231 L17.1767435,18.6256231 Z M24.8370287,17.4177379 C25.922252,17.2355961 26.6543441,16.2081937 26.4722023,15.1229704 C26.2900605,14.0377471 25.2626581,13.3056549 24.1774348,13.4877968 C24.1702314,13.4890057 24.1702314,13.4890057 24.1630282,13.4902145 C23.0777996,13.6723249 22.3456777,14.6997061 22.5277881,15.7849347 C22.7098984,16.8701632 23.7372796,17.6022852 24.8225082,17.4201748 C24.8297684,17.4189565 24.8297684,17.4189565 24.8370287,17.4177379 Z M32.4725265,16.061085 C33.5532108,15.853199 34.2612448,14.8060455 34.0539647,13.7222022 C33.8466846,12.6383589 32.8025831,11.9282552 31.7218988,12.1361412 C31.714724,12.1375214 31.714724,12.1375214 31.7075489,12.1389013 C30.6268567,12.3467457 29.9187826,13.3938719 30.1260211,14.4777232 C30.3332597,15.5615745 31.3773339,16.2717185 32.4580262,16.0638741 C32.4652764,16.0624797 32.4652764,16.0624797 32.4725265,16.061085 Z M40.0707225,14.4695476 C40.0780573,14.4678946 40.0780573,14.4678946 40.0853916,14.4662413 C41.158768,14.2242783 41.8327617,13.1579849 41.5907986,12.0846085 C41.3488355,11.011232 40.2825422,10.3372384 39.2091657,10.5792015 C39.2019419,10.5808298 39.2019419,10.5808298 39.1947175,10.582458 C38.1213273,10.8243601 37.447273,11.8906152 37.6891752,12.9640053 C37.9310773,14.0373955 38.9973324,14.7114498 40.0707225,14.4695476 L40.0707225,14.4695476 Z M47.4276119,12.0082845 C47.4329844,12.0067855 47.4329844,12.0067855 47.4383562,12.0052864 C48.2362896,11.7825897 48.7026111,10.9552056 48.4799145,10.1572722 C48.2572179,9.35933881 47.4298337,8.89301728 46.6319003,9.11571391 C46.6266645,9.1171751 46.6266645,9.1171751 46.6214279,9.11863616 C45.8234736,9.34125773 45.3570742,10.168598 45.5796958,10.9665523 C45.8023173,11.7645067 46.6296576,12.230906 47.4276119,12.0082845 L47.4276119,12.0082845 Z M54.8999721,9.57562965 C54.9052414,9.57358217 54.9052414,9.57358217 54.9105092,9.57153441 C55.6826371,9.27135123 56.0652239,8.40207131 55.7650408,7.62994336 C55.4648576,6.85781542 54.5955777,6.4752286 53.8234497,6.77541179 C53.8184808,6.77734338 53.8184808,6.77734338 53.8135101,6.77927482 C53.0413181,7.07929302 52.6585455,7.94849117 52.9585637,8.72068323 C53.2585819,9.4928753 54.12778,9.87564785 54.8999721,9.57562965 L54.8999721,9.57562965 Z" id="Shape"></path>
+                <path d="M1.45327704,26.6978168 C1.54647464,26.6867112 1.63432439,26.660866 1.7147722,26.6228911 C2.03520341,26.4716332 2.23820252,26.1279362 2.1939679,25.7567213 C2.13862768,25.2923089 1.71728488,24.9606903 1.2528724,25.0160305 C1.24980572,25.0163959 1.24980572,25.0163959 1.24674021,25.0167611 C0.782326598,25.0720918 0.450699376,25.4934278 0.506030077,25.9578415 C0.561360778,26.4222551 0.982696791,26.7538823 1.4471104,26.6985516 C1.45019313,26.6981843 1.45019313,26.6981843 1.45327704,26.6978168 Z M9.34858965,26.1274206 C9.35409106,26.1266859 9.35409106,26.1266859 9.35959333,26.1259509 C10.1807278,26.0162709 10.7574756,25.2616967 10.6477955,24.4405622 C10.5381155,23.6194278 9.78354128,23.04268 8.96240683,23.15236 C8.95693539,23.1530908 8.95693539,23.1530908 8.95146479,23.1538215 C8.13032806,23.2634845 7.55356464,24.0180467 7.66322765,24.8391835 C7.77289065,25.6603202 8.52745292,26.2370836 9.34858965,26.1274206 L9.34858965,26.1274206 Z M17.0066591,25.0462427 C17.0121188,25.0454283 17.0121188,25.0454283 17.0175789,25.0446136 C17.8369369,24.9223683 18.4020584,24.1590479 18.279813,23.3396899 C18.1575677,22.5203319 17.3942473,21.9552104 16.5748893,22.0774558 C16.5694641,22.0782652 16.5694641,22.0782652 16.5640392,22.0790744 C15.7446783,22.2013005 15.1795389,22.9646076 15.301765,23.7839685 C15.4239911,24.6033294 16.1872982,25.1684688 17.0066591,25.0462427 L17.0066591,25.0462427 Z M24.8225082,24.4201748 C24.8297684,24.4189565 24.8297684,24.4189565 24.8370287,24.4177379 C25.922252,24.2355961 26.6543441,23.2081937 26.4722023,22.1229704 C26.2900605,21.0377471 25.2626581,20.3056549 24.1774348,20.4877968 C24.1702314,20.4890057 24.1702314,20.4890057 24.1630282,20.4902145 C23.0777996,20.6723249 22.3456777,21.6997061 22.5277881,22.7849347 C22.7098984,23.8701632 23.7372796,24.6022852 24.8225082,24.4201748 L24.8225082,24.4201748 Z M32.4725265,23.0495399 C33.5532108,22.8422598 34.2612448,21.7981584 34.0539647,20.7174741 C33.8466846,19.6367898 32.8025831,18.9287558 31.7218988,19.1360359 C31.714724,19.137412 31.714724,19.137412 31.7075489,19.138788 C30.6268567,19.3460265 29.9187826,20.3901008 30.1260211,21.470793 C30.3332597,22.5514853 31.3773339,23.2595594 32.4580262,23.0523208 C32.4652764,23.0509305 32.4652764,23.0509305 32.4725265,23.0495399 Z M39.8723866,20.8947688 C39.877909,20.8935242 39.877909,20.8935242 39.883431,20.8922795 C40.6915794,20.7101047 41.1990314,19.9072892 41.0168566,19.0991407 C40.8346818,18.2909923 40.0318663,17.7835404 39.2237179,17.9657152 C39.218279,17.9669412 39.218279,17.9669412 39.2128397,17.968167 C38.404681,18.1502959 37.8971834,18.9530826 38.0793123,19.7612414 C38.2614411,20.5694001 39.0642279,21.0768976 39.8723866,20.8947688 L39.8723866,20.8947688 Z M47.4276119,19.0082845 C47.4329844,19.0067855 47.4329844,19.0067855 47.4383562,19.0052864 C48.2362896,18.7825897 48.7026111,17.9552056 48.4799145,17.1572722 C48.2572179,16.3593388 47.4298337,15.8930173 46.6319003,16.1157139 C46.6266645,16.1171751 46.6266645,16.1171751 46.6214279,16.1186362 C45.8234736,16.3412577 45.3570742,17.168598 45.5796958,17.9665523 C45.8023173,18.7645067 46.6296576,19.230906 47.4276119,19.0082845 L47.4276119,19.0082845 Z M54.4138099,15.7087505 C54.4167849,15.7075945 54.4167849,15.7075945 54.419759,15.7064383 C54.8556933,15.5369585 55.0716973,15.0461733 54.9022174,14.610239 C54.7327376,14.1743047 54.2419524,13.9583007 53.8060181,14.1277806 C53.8032127,14.1288712 53.8032127,14.1288712 53.8004064,14.1299616 C53.3644359,14.2993484 53.148327,14.7900873 53.3177137,15.2260578 C53.4871005,15.6620283 53.9778394,15.8781372 54.4138099,15.7087505 L54.4138099,15.7087505 Z" id="Shape"></path>
+            </g>
+            <g id="top">
+                <path d="M1.4471104,12.2885536 C1.45019313,12.2881864 1.45019313,12.2881864 1.45327704,12.2878189 C1.91768952,12.2324787 2.24930811,11.8111359 2.1939679,11.3467234 C2.13862768,10.8823109 1.71728488,10.5506923 1.2528724,10.6060325 C1.24980572,10.606398 1.24980572,10.606398 1.24674021,10.6067632 C0.782326598,10.6620939 0.450699376,11.0834299 0.506030077,11.5478435 C0.561360778,12.0122571 0.982696791,12.3438844 1.4471104,12.2885536 L1.4471104,12.2885536 Z M9.34858965,12.1304907 C9.35409106,12.129756 9.35409106,12.129756 9.35959333,12.129021 C10.1807278,12.019341 10.7574756,11.2647668 10.6477955,10.4436323 C10.5381155,9.62249789 9.78354128,9.04575011 8.96240683,9.15543014 C8.95693539,9.15616095 8.95693539,9.15616095 8.95146479,9.15689157 C8.13032806,9.26655457 7.55356464,10.0211168 7.66322765,10.8422536 C7.77289065,11.6633903 8.52745292,12.2401537 9.34858965,12.1304907 L9.34858965,12.1304907 Z M17.0066591,11.0493128 C17.0121188,11.0484984 17.0121188,11.0484984 17.0175789,11.0476838 C17.8369369,10.9254384 18.4020584,10.1621181 18.279813,9.34276003 C18.1575677,8.52340201 17.3942473,7.95828052 16.5748893,8.08052587 C16.5694641,8.08133528 16.5694641,8.08133528 16.5640392,8.08214454 C15.7446783,8.20437064 15.1795389,8.96767771 15.301765,9.78703861 C15.4239911,10.6063995 16.1872982,11.1715389 17.0066591,11.0493128 L17.0066591,11.0493128 Z M24.8225082,10.4232459 C24.8297684,10.4220275 24.8297684,10.4220275 24.8370287,10.420809 C25.922252,10.2386672 26.6543441,9.21126476 26.4722023,8.12604147 C26.2900605,7.04081818 25.2626581,6.30872601 24.1774348,6.49086783 C24.1702314,6.4920768 24.1702314,6.4920768 24.1630282,6.49328559 C23.0777996,6.67539597 22.3456777,7.70277717 22.5277881,8.78800574 C22.7098984,9.87323431 23.7372796,10.6053563 24.8225082,10.4232459 L24.8225082,10.4232459 Z M32.4725265,9.05261002 C33.5532108,8.84532993 34.2612448,7.80122849 34.0539647,6.72054419 C33.8466846,5.63985989 32.8025831,4.93182589 31.7218988,5.13910599 C31.714724,5.14048211 31.714724,5.14048211 31.7075489,5.14185807 C30.6268567,5.34909665 29.9187826,6.39317088 30.1260211,7.47386314 C30.3332597,8.5545554 31.3773339,9.26262952 32.4580262,9.05539095 C32.4652764,9.05400057 32.4652764,9.05400057 32.4725265,9.05261002 Z M39.8723866,6.89476879 C39.877909,6.8935242 39.877909,6.8935242 39.883431,6.89227947 C40.6915794,6.71010471 41.1990314,5.90728916 41.0168566,5.09914075 C40.8346818,4.29099233 40.0318663,3.78354042 39.2237179,3.96571517 C39.218279,3.96694116 39.218279,3.96694116 39.2128397,3.96816703 C38.404681,4.15029588 37.8971834,4.9530826 38.0793123,5.76124136 C38.2614411,6.56940012 39.0642279,7.07689764 39.8723866,6.89476879 L39.8723866,6.89476879 Z M47.4276119,5.00828445 C47.4329844,5.00678549 47.4329844,5.00678549 47.4383562,5.00528637 C48.2362896,4.78258973 48.7026111,3.95520561 48.4799145,3.15727221 C48.2572179,2.35933881 47.4298337,1.89301728 46.6319003,2.11571391 C46.6266645,2.1171751 46.6266645,2.1171751 46.6214279,2.11863616 C45.8234736,2.34125773 45.3570742,3.16859798 45.5796958,3.96655233 C45.8023173,4.76450667 46.6296576,5.23090603 47.4276119,5.00828445 L47.4276119,5.00828445 Z M54.419759,2.30643871 C54.8556933,2.13695884 55.0716973,1.6461737 54.9022174,1.21023941 C54.7327376,0.774305114 54.2419524,0.558301127 53.8060181,0.727780997 C53.8032127,0.728871549 53.8032127,0.728871549 53.8004064,0.729962021 C53.3644359,0.89934874 53.148327,1.39008772 53.3177137,1.82605822 C53.4871005,2.26202871 53.9778394,2.47813756 54.4138099,2.30875084 C54.4167849,2.30759485 54.4167849,2.30759485 54.419759,2.30643871 Z" id="Shape"></path>
+                <path d="M1.67760355,20.096503 C1.68306395,20.0958524 1.68306395,20.0958524 1.68852642,20.0952015 C2.51113381,19.9971782 3.09852524,19.2508595 3.00050189,18.4282521 C2.90247854,17.6056447 2.15615986,17.0182533 1.33355246,17.1162767 C1.3281205,17.1169239 1.3281205,17.1169239 1.3226906,17.1175709 C0.500081196,17.2155774 -0.0873255124,17.961884 0.0106809923,18.7844934 C0.108687497,19.6071028 0.854994145,20.1945095 1.67760355,20.096503 L1.67760355,20.096503 Z M9.34858965,19.1274206 C9.35409106,19.1266859 9.35409106,19.1266859 9.35959333,19.1259509 C10.1807278,19.0162709 10.7574756,18.2616967 10.6477955,17.4405622 C10.5381155,16.6194278 9.78354128,16.04268 8.96240683,16.15236 C8.95693539,16.1530908 8.95693539,16.1530908 8.95146479,16.1538215 C8.13032806,16.2634845 7.55356464,17.0180467 7.66322765,17.8391835 C7.77289065,18.6603202 8.52745292,19.2370836 9.34858965,19.1274206 L9.34858965,19.1274206 Z M17.1767435,18.6256231 C17.1839958,18.6245412 17.1839958,18.6245412 17.1912486,18.6234592 C18.27963,18.4610765 19.0303002,17.4471319 18.8679175,16.3587506 C18.7055348,15.2703693 17.6915903,14.519699 16.6032089,14.6820817 C16.5960024,14.6831569 16.5960024,14.6831569 16.5887964,14.6842319 C15.5004112,14.846589 14.7497172,15.8605159 14.9120743,16.948901 C15.0744314,18.0372862 16.0883584,18.7879802 17.1767435,18.6256231 L17.1767435,18.6256231 Z M24.8370287,17.4177379 C25.922252,17.2355961 26.6543441,16.2081937 26.4722023,15.1229704 C26.2900605,14.0377471 25.2626581,13.3056549 24.1774348,13.4877968 C24.1702314,13.4890057 24.1702314,13.4890057 24.1630282,13.4902145 C23.0777996,13.6723249 22.3456777,14.6997061 22.5277881,15.7849347 C22.7098984,16.8701632 23.7372796,17.6022852 24.8225082,17.4201748 C24.8297684,17.4189565 24.8297684,17.4189565 24.8370287,17.4177379 Z M32.4725265,16.061085 C33.5532108,15.853199 34.2612448,14.8060455 34.0539647,13.7222022 C33.8466846,12.6383589 32.8025831,11.9282552 31.7218988,12.1361412 C31.714724,12.1375214 31.714724,12.1375214 31.7075489,12.1389013 C30.6268567,12.3467457 29.9187826,13.3938719 30.1260211,14.4777232 C30.3332597,15.5615745 31.3773339,16.2717185 32.4580262,16.0638741 C32.4652764,16.0624797 32.4652764,16.0624797 32.4725265,16.061085 Z M40.0707225,14.4695476 C40.0780573,14.4678946 40.0780573,14.4678946 40.0853916,14.4662413 C41.158768,14.2242783 41.8327617,13.1579849 41.5907986,12.0846085 C41.3488355,11.011232 40.2825422,10.3372384 39.2091657,10.5792015 C39.2019419,10.5808298 39.2019419,10.5808298 39.1947175,10.582458 C38.1213273,10.8243601 37.447273,11.8906152 37.6891752,12.9640053 C37.9310773,14.0373955 38.9973324,14.7114498 40.0707225,14.4695476 L40.0707225,14.4695476 Z M47.4276119,12.0082845 C47.4329844,12.0067855 47.4329844,12.0067855 47.4383562,12.0052864 C48.2362896,11.7825897 48.7026111,10.9552056 48.4799145,10.1572722 C48.2572179,9.35933881 47.4298337,8.89301728 46.6319003,9.11571391 C46.6266645,9.1171751 46.6266645,9.1171751 46.6214279,9.11863616 C45.8234736,9.34125773 45.3570742,10.168598 45.5796958,10.9665523 C45.8023173,11.7645067 46.6296576,12.230906 47.4276119,12.0082845 L47.4276119,12.0082845 Z M54.8999721,9.57562965 C54.9052414,9.57358217 54.9052414,9.57358217 54.9105092,9.57153441 C55.6826371,9.27135123 56.0652239,8.40207131 55.7650408,7.62994336 C55.4648576,6.85781542 54.5955777,6.4752286 53.8234497,6.77541179 C53.8184808,6.77734338 53.8184808,6.77734338 53.8135101,6.77927482 C53.0413181,7.07929302 52.6585455,7.94849117 52.9585637,8.72068323 C53.2585819,9.4928753 54.12778,9.87564785 54.8999721,9.57562965 L54.8999721,9.57562965 Z" id="Shape"></path>
+                <path d="M1.45327704,26.6978168 C1.54647464,26.6867112 1.63432439,26.660866 1.7147722,26.6228911 C2.03520341,26.4716332 2.23820252,26.1279362 2.1939679,25.7567213 C2.13862768,25.2923089 1.71728488,24.9606903 1.2528724,25.0160305 C1.24980572,25.0163959 1.24980572,25.0163959 1.24674021,25.0167611 C0.782326598,25.0720918 0.450699376,25.4934278 0.506030077,25.9578415 C0.561360778,26.4222551 0.982696791,26.7538823 1.4471104,26.6985516 C1.45019313,26.6981843 1.45019313,26.6981843 1.45327704,26.6978168 Z M9.34858965,26.1274206 C9.35409106,26.1266859 9.35409106,26.1266859 9.35959333,26.1259509 C10.1807278,26.0162709 10.7574756,25.2616967 10.6477955,24.4405622 C10.5381155,23.6194278 9.78354128,23.04268 8.96240683,23.15236 C8.95693539,23.1530908 8.95693539,23.1530908 8.95146479,23.1538215 C8.13032806,23.2634845 7.55356464,24.0180467 7.66322765,24.8391835 C7.77289065,25.6603202 8.52745292,26.2370836 9.34858965,26.1274206 L9.34858965,26.1274206 Z M17.0066591,25.0462427 C17.0121188,25.0454283 17.0121188,25.0454283 17.0175789,25.0446136 C17.8369369,24.9223683 18.4020584,24.1590479 18.279813,23.3396899 C18.1575677,22.5203319 17.3942473,21.9552104 16.5748893,22.0774558 C16.5694641,22.0782652 16.5694641,22.0782652 16.5640392,22.0790744 C15.7446783,22.2013005 15.1795389,22.9646076 15.301765,23.7839685 C15.4239911,24.6033294 16.1872982,25.1684688 17.0066591,25.0462427 L17.0066591,25.0462427 Z M24.8225082,24.4201748 C24.8297684,24.4189565 24.8297684,24.4189565 24.8370287,24.4177379 C25.922252,24.2355961 26.6543441,23.2081937 26.4722023,22.1229704 C26.2900605,21.0377471 25.2626581,20.3056549 24.1774348,20.4877968 C24.1702314,20.4890057 24.1702314,20.4890057 24.1630282,20.4902145 C23.0777996,20.6723249 22.3456777,21.6997061 22.5277881,22.7849347 C22.7098984,23.8701632 23.7372796,24.6022852 24.8225082,24.4201748 L24.8225082,24.4201748 Z M32.4725265,23.0495399 C33.5532108,22.8422598 34.2612448,21.7981584 34.0539647,20.7174741 C33.8466846,19.6367898 32.8025831,18.9287558 31.7218988,19.1360359 C31.714724,19.137412 31.714724,19.137412 31.7075489,19.138788 C30.6268567,19.3460265 29.9187826,20.3901008 30.1260211,21.470793 C30.3332597,22.5514853 31.3773339,23.2595594 32.4580262,23.0523208 C32.4652764,23.0509305 32.4652764,23.0509305 32.4725265,23.0495399 Z M39.8723866,20.8947688 C39.877909,20.8935242 39.877909,20.8935242 39.883431,20.8922795 C40.6915794,20.7101047 41.1990314,19.9072892 41.0168566,19.0991407 C40.8346818,18.2909923 40.0318663,17.7835404 39.2237179,17.9657152 C39.218279,17.9669412 39.218279,17.9669412 39.2128397,17.968167 C38.404681,18.1502959 37.8971834,18.9530826 38.0793123,19.7612414 C38.2614411,20.5694001 39.0642279,21.0768976 39.8723866,20.8947688 L39.8723866,20.8947688 Z M47.4276119,19.0082845 C47.4329844,19.0067855 47.4329844,19.0067855 47.4383562,19.0052864 C48.2362896,18.7825897 48.7026111,17.9552056 48.4799145,17.1572722 C48.2572179,16.3593388 47.4298337,15.8930173 46.6319003,16.1157139 C46.6266645,16.1171751 46.6266645,16.1171751 46.6214279,16.1186362 C45.8234736,16.3412577 45.3570742,17.168598 45.5796958,17.9665523 C45.8023173,18.7645067 46.6296576,19.230906 47.4276119,19.0082845 L47.4276119,19.0082845 Z M54.4138099,15.7087505 C54.4167849,15.7075945 54.4167849,15.7075945 54.419759,15.7064383 C54.8556933,15.5369585 55.0716973,15.0461733 54.9022174,14.610239 C54.7327376,14.1743047 54.2419524,13.9583007 53.8060181,14.1277806 C53.8032127,14.1288712 53.8032127,14.1288712 53.8004064,14.1299616 C53.3644359,14.2993484 53.148327,14.7900873 53.3177137,15.2260578 C53.4871005,15.6620283 53.9778394,15.8781372 54.4138099,15.7087505 L54.4138099,15.7087505 Z" id="Shape"></path>
+            </g>
+        </g>
+    </g>
+</svg>
+
+        </a>
+    </li>
+    
+    
+    <li><a href=".././blog/index.html">Blog</a></li>
+    
+    <li><a href=".././docs/index.html">Docs</a></li>
+    
+    <li><a class="toggle-children" onclick='(function(){var child=document.getElementById("Usage");child.classList.toggle("show");child.classList.toggle("hide");})();'>Usage</a>
+<ul id="Usage" class="hide">
+    <li><a href=".././docs/usage/cbt-projects.html">cbt-projects</a></li><li><a href=".././docs/usage/sbt-projects.html">sbt-projects</a></li><li><a href=".././docs/usage/dottydoc.html">Dottydoc</a></li><li><a href=".././docs/usage/migrating.html">Migrating</a></li>
+</ul></li>
+    
+    <li><a class="toggle-children" onclick='(function(){var child=document.getElementById("Contributing");child.classList.toggle("show");child.classList.toggle("hide");})();'>Contributing</a>
+<ul id="Contributing" class="hide">
+    <li><a href=".././docs/contributing/eclipse.html">Eclipse</a></li><li><a href=".././docs/contributing/getting-started.html">Getting Started</a></li><li><a href=".././docs/contributing/intellij-idea.html">IntelliJ IDEA</a></li><li><a href=".././docs/contributing/workflow.html">Workflow</a></li>
+</ul></li>
+    
+    <li><a class="toggle-children" onclick='(function(){var child=document.getElementById("Internals");child.classList.toggle("show");child.classList.toggle("hide");})();'>Internals</a>
+<ul id="Internals" class="hide">
+    <li><a href=".././docs/internals/backend.html">Backend</a></li><li><a href=".././docs/internals/benchmarks.html">Benchmarks</a></li><li><a href=".././docs/internals/classpaths.html">Classpaths</a></li><li><a href=".././docs/internals/core-data-structures.html">Core Data Structrues</a></li><li><a href=".././docs/internals/contexts.html">Contexts</a></li><li><a href=".././docs/internals/dotc-scalac.html">Dotc vs Scalac</a></li><li><a href=".././docs/internals/higher-kinded-v2.html">Higher-Kinded Types</a></li><li><a href=".././docs/internals/overall-structure.html">Overall Structure</a></li><li><a href=".././docs/internals/periods.html">Periods</a></li><li><a href=".././docs/internals/syntax.html">Syntax</a></li><li><a href=".././docs/internals/type-system.html">Type System</a></li>
+</ul></li>
+    
+</ul>
+
+        <ul class="index-entities">
+        
+        <li class="index-title">
+            <span>API</span>
+        </li>
+        
+        
+            <li class="index-entity entity-package">
+                <a class="entity-name" href=".././api/foo/index.html">foo</a>
+            </li>
+            
+                
+                <li class="index-entity ">
+                    <div class="entity-kinds">
+                        
+                        <a class="letter-anchor object" href=".././api/foo/Foo$.html">O</a>
+                    </div>
+                    <a class="entity-name" href=".././api/foo/Foo$.html">Foo</a>
+                </li>
+                
+            
+        
+        </ul>
+    </div>
+    <div id="content-body">
+        <div id="menu-toggle" onclick="toggleMenu()">
+            <i class="fa fa-bars" aria-hidden="true"></i>
+        </div>
+        
+<div id="post-title">
+    <h3 id="post-date">
+        
+    </h3>
+    <h1 id="main-title">Blog</h1>
+    
+</div>
+
+<div id="blog-post-container">
+    
+<ul class="post-list">
+    
+    <li>
+        <div>
+            <a href=".././blog/2016/12/05/implicit-function-types.html">Implicit Function Types</a>
+        </div>
+        <div class="date">
+            
+        </div>
+        <div class="excerpt">
+            <p>I just made the <a href="https://github.com/lampepfl/dotty/pull/1775">first pull request</a> to add <em>implicit function types</em> to
+Scala. I am pretty excited about it, because - citing the explanation
+of the pull request - &quot;<em>This is the first step to bring contextual
+abstraction to Scala</em>&quot;. What do I mean by this?</p>
+        </div>
+    </li>
+    
+    <li>
+        <div>
+            <a href=".././blog/2016/05/05/multiversal-equality.html">Multiversal Equality for Scala</a>
+        </div>
+        <div class="date">
+            
+        </div>
+        <div class="excerpt">
+            <p>I have been working recently on making equality tests using <code>==</code> and <code>!=</code> safer in Scala. This has led to a <a href="https://github.com/lampepfl/dotty/issues/1247">Language Enhancement Proposal</a> which I summarize in this blog.</p>
+        </div>
+    </li>
+    
+    <li>
+        <div>
+            <a href=".././blog/2016/02/17/scaling-dot-soundness.html">Scaling DOT to Scala - Soundness</a>
+        </div>
+        <div class="date">
+            
+        </div>
+        <div class="excerpt">
+            <p>In my <a href="http://www.scala-lang.org/blog/2016/02/03/essence-of-scala.html">last
+blog post</a>
+I introduced DOT, a minimal calculus that underlies much of Scala.
+DOT is much more than an academic exercise, because it gives us
+guidelines on how to design a sound type system for full Scala.</p>
+        </div>
+    </li>
+    
+    <li>
+        <div>
+            <a href=".././blog/2016/02/03/essence-of-scala.html">The Essence of Scala</a>
+        </div>
+        <div class="date">
+            
+        </div>
+        <div class="excerpt">
+            <p>What do you get if you boil Scala on a slow flame and wait until all
+incidental features evaporate and only the most concentrated essence
+remains? After doing this for 8 years we believe we have the answer:
+it's DOT, the calculus of dependent object types, that underlies Scala.</p>
+        </div>
+    </li>
+    
+    <li>
+        <div>
+            <a href=".././blog/2016/01/02/new-year-resolutions.html">New Year Resolutions</a>
+        </div>
+        <div class="date">
+            
+        </div>
+        <div class="excerpt">
+            <p>For most of us, the change of the year is an occasion for thinking
+about what we missed doing last year and where we want to improve. I decided
+there are a couple of things where I would like to do better in 2016
+than in 2015. The first is that I would like to do more blogging and
+writing in general. I have been pretty silent for most of the last
+year. This was mostly caused by the fact that I had been heads down to
+work on DOT, Scala's foundations, and <em>dotty</em>, the new Scala compiler
+platform we are working on. It's been a lot of work, but we are finally
+getting good results. DOT now has a mechanized proof of type soundness
+and the dotty compiler <a href="http://www.scala-lang.org/blog/2015/10/23/dotty-compiler-bootstraps.html">can now compile
+itself</a>
+as well as large parts of Scala's standard library.</p>
+        </div>
+    </li>
+    
+    <li>
+        <div>
+            <a href=".././blog/2015/10/23/dotty-compiler-bootstraps.html">We got liftoff!</a>
+        </div>
+        <div class="date">
+            
+        </div>
+        <div class="excerpt">
+            <p>The <a href="https://github.com/lampepfl/dotty">Dotty project</a>
+is a platform to develop new technology for Scala
+tooling and to try out concepts of future Scala language versions.
+Its compiler is a new design intended to reflect the
+lessons we learned from work with the Scala compiler. A clean redesign
+today will let us iterate faster with new ideas in the future.</p>
+<p>Today we reached an important milestone: the Dotty compiler can
+compile itself, and the compiled compiler can act as a drop-in for the
+original one. This is what one calls a <em>bootstrap</em>.</p>
+
+        </div>
+    </li>
+    
+</ul>
+</div>
+
+
+    </div>
+</div>
+
+
+<script>
+function toggleMenu() {
+    var wrapper = document.getElementById("content-wrapper");
+    wrapper.classList.toggle("toggled");
+}
+</script>
+
+        <script
+            src="https://ajax.googleapis.com/ajax/libs/jquery/3.1.1/jquery.min.js"
+            integrity="sha384-3ceskX3iaEnIogmQchP8opvBy3Mi7Ce34nWjpBIwVTHfGYWQS9jwHDVRnpKKHJg7"
+            crossorigin="anonymous"
+        ></script>
+        <script
+            src="https://cdnjs.cloudflare.com/ajax/libs/tether/1.3.7/js/tether.min.js"
+            integrity="sha384-XTs3FgkjiBgo8qjEjBk0tGmf3wPrWtA6coPfQDfFEY8AnYJwjalXCiosYRBIBZX8"
+            crossorigin="anonymous"
+        ></script>
+        <script
+            src="https://maxcdn.bootstrapcdn.com/bootstrap/4.0.0-alpha.5/js/bootstrap.min.js"
+            integrity="sha384-BLiI7JTZm+JWlgKa0M0kGRpJbF2J8q+qreVrKBC47e3K6BW78kGLrCkeRX6I9RoK"
+            crossorigin="anonymous"
+        ></script>
+        <script src=".././js/highlight.pack.js"></script>
+        
+        <script>
+            $(document).ready(function() {
+                $('pre code').each(function(i, block) {
+                    hljs.highlightBlock(block);
+                });
+            });
+        </script>
+    </body>
+</html>