All paragraphs are now separate lines to simplify PRs

Author: alvinj

_overviews/scala3-book/ca-context-bounds.md

@@ -14,7 +14,8 @@ next-page: ca-given-imports
 {% endcomment %}
 
 
-In many situations the name of a *context parameter* doesn’t have to be mentioned explicitly, since it’s only used in synthesized arguments for other context parameters. In that case you don’t have to define a parameter name, and can just provide the parameter type.
+In many situations the name of a *context parameter* doesn’t have to be mentioned explicitly, since it’s only used in synthesized arguments for other context parameters.
+In that case you don’t have to define a parameter name, and can just provide the parameter type.
 
 
 ## Background

_overviews/scala3-book/ca-contextual-abstractions-intro.md

@@ -10,37 +10,53 @@ next-page: ca-given-using-clauses
 
 ## Background
 
-Implicits in Scala 2 were a major distinguishing design feature. They are *the* fundamental way to abstract over context. They represent a unified paradigm with a great variety of use cases, among them:
+Implicits in Scala 2 were a major distinguishing design feature.
+They are *the* fundamental way to abstract over context.
+They represent a unified paradigm with a great variety of use cases, among them:
 
 - Implementing type classes
 - Establishing context
 - Dependency injection
 - Expressing capabilities
 - Computing new types, and proving relationships between them
 
-Since then, other languages have followed suit, e.g., Rust’s traits or Swift’s protocol extensions. Design proposals are also on the table for Kotlin as compile time dependency resolution, for C# as Shapes and Extensions or for F# as Traits. Implicits are also a common feature of theorem provers such as Coq or Agda.
+Since then, other languages have followed suit, e.g., Rust’s traits or Swift’s protocol extensions.
+Design proposals are also on the table for Kotlin as compile time dependency resolution, for C# as Shapes and Extensions or for F# as Traits.
+Implicits are also a common feature of theorem provers such as Coq or Agda.
 
-Even though these designs use different terminology, they’re all variants of the core idea of *term inference*: Given a type, the compiler synthesizes a “canonical” term that has that type.
+Even though these designs use different terminology, they’re all variants of the core idea of *term inference*:
+Given a type, the compiler synthesizes a “canonical” term that has that type.
 
 
 ## Redesign
 
-Scala 3 includes a redesign of contextual abstractions in Scala. While these concepts were gradually “discovered” in Scala 2, they’re now well known and understood, and the redesign takes advantage of that knowledge.
+Scala 3 includes a redesign of contextual abstractions in Scala.
+While these concepts were gradually “discovered” in Scala 2, they’re now well known and understood, and the redesign takes advantage of that knowledge.
 
 The design of Scala 3 focuses on **intent** rather than **mechanism**.
 Instead of offering one very powerful feature of implicits, Scala 3 offers several use-case oriented features:
 
-- **Abtracting over contextual information**. [Using clauses][givens] allow programmers to abstract over information that is available in the calling context and should be passed implicitly. As an improvement over Scala 2 implicits, using clauses can be specified by type, freeing function signatures from term variable names that are never explicitly referred to.
+- **Abtracting over contextual information**.
+  [Using clauses][givens] allow programmers to abstract over information that is available in the calling context and should be passed implicitly.
+  As an improvement over Scala 2 implicits, using clauses can be specified by type, freeing function signatures from term variable names that are never explicitly referred to.
 
-- **Providing Type-class instances**. [Given instances][type-classes] allow programmers to define the _canonical value_ of a certain type. This makes programming with type-classes more straightforward without leaking implementation details.
+- **Providing Type-class instances**.
+  [Given instances][type-classes] allow programmers to define the _canonical value_ of a certain type.
+  This makes programming with type-classes more straightforward without leaking implementation details.
 
-- **Retroactively extending classes**. In Scala 2, extension methods had to be encoded using implicit conversions or implicit classes. In contrast, in Scala 3 [extension methods][extension-methods] are now directly built into the language, leading to better error messages and improved type inference.
+- **Retroactively extending classes**.
+  In Scala 2, extension methods had to be encoded using implicit conversions or implicit classes.
+  In contrast, in Scala 3 [extension methods][extension-methods] are now directly built into the language, leading to better error messages and improved type inference.
 
-- **Viewing one type as another**. Implicit conversion have been [redesigned][implicit-conversions] from the ground up as instances of a type-class `Conversion`.
+- **Viewing one type as another**.
+  Implicit conversion have been [redesigned][implicit-conversions] from the ground up as instances of a type-class `Conversion`.
 
-- **Higher-order contextual abstractions**. The _all-new_ feature of [context functions][contextual-functions] makes contextual abstractions a first-class citizen. They are an important tool for library authors and allow to express concise domain specific languages.
+- **Higher-order contextual abstractions**.
+  The _all-new_ feature of [context functions][contextual-functions] makes contextual abstractions a first-class citizen.
+  They are an important tool for library authors and allow to express concise domain specific languages.
 
-- **Actionable feedback from the compiler**. In case an implicit parameter can not be resolved by the compiler, it now provides you [import suggestions](https://www.scala-lang.org/blog/2020/05/05/scala-3-import-suggestions.html) that may fix the problem.
+- **Actionable feedback from the compiler**.
+  In case an implicit parameter can not be resolved by the compiler, it now provides you [import suggestions](https://www.scala-lang.org/blog/2020/05/05/scala-3-import-suggestions.html) that may fix the problem.
 
 
 ## Benefits

_overviews/scala3-book/ca-extension-methods.md

@@ -8,13 +8,15 @@ next-page: ca-type-classes
 ---
 
 
-Extension methods let you add methods to a type after the type is defined, i.e., they let you add new methods to closed classes. For example, imagine that someone else has created a `Circle` class:
+Extension methods let you add methods to a type after the type is defined, i.e., they let you add new methods to closed classes.
+For example, imagine that someone else has created a `Circle` class:
 
 ```scala
 case class Circle(x: Double, y: Double, radius: Double)
 ```
 
-Now imagine that you need a `circumference` method, but you can’t modify their source code. Before the concept of term inference was introduced into programming languages, the only thing you could do was write a method in a separate class or object like this:
+Now imagine that you need a `circumference` method, but you can’t modify their source code.
+Before the concept of term inference was introduced into programming languages, the only thing you could do was write a method in a separate class or object like this:
 
 ```scala
 object CircleHelpers:
@@ -49,7 +51,8 @@ aCircle.circumference
 
 ## Discussion
 
-The `extension` keyword declares that you’re about to define one or more extension methods on the type that’s put in parentheses. To define multiple extension methods on a type, use this syntax:
+The `extension` keyword declares that you’re about to define one or more extension methods on the type that’s put in parentheses.
+To define multiple extension methods on a type, use this syntax:
 
 ```scala
 extension (c: Circle)

_overviews/scala3-book/ca-given-imports.md

@@ -8,7 +8,8 @@ next-page: ca-extension-methods
 ---
 
 
-To make it more clear where givens in the current scope are coming from, a special form of the `import` statement is used to import `given` instances. The basic form is shown in this example:
+To make it more clear where givens in the current scope are coming from, a special form of the `import` statement is used to import `given` instances.
+The basic form is shown in this example:
 
 ```scala
 object A:
@@ -21,7 +22,9 @@ object B:
   import A.given   // import the given instance
 ```
 
-In this code the `import A._` clause of object `B` imports all members of `A` *except* the `given` instance, `tc`. Conversely, the second import, `import A.given`, imports *only* that `given` instance. The two `import` clauses can also be merged into one:
+In this code the `import A._` clause of object `B` imports all members of `A` *except* the `given` instance, `tc`.
+Conversely, the second import, `import A.given`, imports *only* that `given` instance.
+The two `import` clauses can also be merged into one:
 
 ```scala
 object B:
@@ -35,8 +38,10 @@ The wildcard selector `_` brings all definitions other than givens or extensions
 
 These rules have two main benefits:
 
-- It’s more clear where givens in the current scope are coming from. In particular, it’s not possible to hide imported givens in a long list of other wildcard imports.
-- It enables importing all givens without importing anything else. This is important because givens can be anonymous, so the usual use of named imports is not practical.
+- It’s more clear where givens in the current scope are coming from.
+  In particular, it’s not possible to hide imported givens in a long list of other wildcard imports.
+- It enables importing all givens without importing anything else.
+  This is important because givens can be anonymous, so the usual use of named imports is not practical.
 
 More examples of the “import given” syntax are shown in the [Packaging and Imports chapter][imports].
 

_overviews/scala3-book/ca-given-using-clauses.md

@@ -13,7 +13,8 @@ Scala 3 offers two important feature for contextual abstraction:
 - **Given Instances** let you define terms that can be used by the Scala compiler to fill in the missing arguments.
 
 ## Using Clauses
-When designing a system, often context information like _configuration_ or settings need to be provided to the different components of your system. One common way to achieve this is by passing the configuration as additional argument to your methods.
+When designing a system, often context information like _configuration_ or settings need to be provided to the different components of your system.
+One common way to achieve this is by passing the configuration as additional argument to your methods.
 
 In the following example, we define a case class `Config` to model some website configuration and pass it around in the different methods.
 ```scala
@@ -27,7 +28,8 @@ def renderWidget(items: List[String], c: Config): String = ???
 val config = Config(8080, "docs.scala-lang.org")
 renderWebsite("/home")(config)
 ```
-Let us assume that the configuration does not change throughout most of our code base. Passing `c` to each and every method call (like `renderWidget`) becomes very tedious and makes our program more difficult to read, since we need to ignore the `c` argument.
+Let us assume that the configuration does not change throughout most of our code base.
+Passing `c` to each and every method call (like `renderWidget`) becomes very tedious and makes our program more difficult to read, since we need to ignore the `c` argument.
 
 #### Using `using` to mark parameters as contextual
 In Scala 3, we can mark some of the parameters of our methods as _contextual_.
@@ -39,9 +41,11 @@ def renderWebsite(path: String)(using c: Config): String =
 
 def renderWidget(items: List[String])(using c: Config): String = ???
 ```
-By starting a parameter section with the keyword `using`, we tell the Scala compiler that at the callsite it should automatically find an argument with the correct type. The Scala compiler thus performs **term inference**.
+By starting a parameter section with the keyword `using`, we tell the Scala compiler that at the callsite it should automatically find an argument with the correct type.
+The Scala compiler thus performs **term inference**.
 
-In our call to `renderWidget(List("cart"))` the Scala compiler will see that there is a term of type `Config` in scope (the `c`) and automatically provide it to `renderWidget`. So the program is equivalent to the one above.
+In our call to `renderWidget(List("cart"))` the Scala compiler will see that there is a term of type `Config` in scope (the `c`) and automatically provide it to `renderWidget`.
+So the program is equivalent to the one above.
 
 In fact, since we do not need to refer to `c` in our implementation of `renderWebsite` anymore, we can even omit it in the signature:
 
@@ -53,7 +57,8 @@ def renderWebsite(path: String)(using Config): String =
 ```
 
 #### Explicitly providing contextual arguments
-We have seen how to _abstract_ over contextual parameters and that the Scala compiler can provide arguments automatically for us. But how can we specify which configuration to use for our call to `renderWebsite`?
+We have seen how to _abstract_ over contextual parameters and that the Scala compiler can provide arguments automatically for us.
+But how can we specify which configuration to use for our call to `renderWebsite`?
 
 Like we specified our parameter section with `using`, we can also explicitly provide contextual arguments with `using:`
 
@@ -65,7 +70,8 @@ Explicitly providing contextual parameters can be useful if we have multiple dif
 For all other cases, as we will see in the next Section, there is also another way to bring contextual values into scope.
 
 ## Given Instances
-We have seen that we can explicitly pass arguments as contextual parameters by marking the argument section of the _call_ with `using`. However, if there is _a single canonical value_ for a particular type, there is another preferred way to make it available to the Scala compiler: by marking it as `given`.
+We have seen that we can explicitly pass arguments as contextual parameters by marking the argument section of the _call_ with `using`.
+However, if there is _a single canonical value_ for a particular type, there is another preferred way to make it available to the Scala compiler: by marking it as `given`.
 
 ```scala
 val config = Config(8080, "docs.scala-lang.org")

_overviews/scala3-book/ca-implicit-conversions.md

@@ -8,7 +8,8 @@ next-page: ca-summary
 ---
 
 
-Implicit conversions are defined by `given` instances of the _scala.Conversion_ class. For example, not accounting for possible conversion errors, this code defines an an implicit conversion from `String` to `Int`:
+Implicit conversions are defined by `given` instances of the _scala.Conversion_ class.
+For example, not accounting for possible conversion errors, this code defines an an implicit conversion from `String` to `Int`:
 
 ```scala
 given Conversion[String, Int] with
@@ -35,7 +36,8 @@ plus1("1")
 
 ## Discussion
 
-The Predef package contains “auto-boxing” conversions that map primitive number types to subclasses of _java.lang.Number_. For instance, the conversion from `Int` to _java.lang.Integer_ can be defined as follows:
+The Predef package contains “auto-boxing” conversions that map primitive number types to subclasses of _java.lang.Number_.
+For instance, the conversion from `Int` to _java.lang.Integer_ can be defined as follows:
 
 ```scala
 given int2Integer: Conversion[Int, java.lang.Integer] =