s/parallel/concurrent/g

Author: bakkot

README.md

@@ -3,7 +3,7 @@
 A proposal for several interfaces that will help with general usage and
 consumption of async iterators in ECMAScript.
 
-This proposal was split out from [proposal-iterator-helpers](https://github.com/tc39/proposal-iterator-helpers) to resolve design questions related to parallelism, which are not relevant to sync helpers. Many design questions (including choice of methods) were discussed and decided in that respository, and its readme should be read first.
+This proposal was split out from [proposal-iterator-helpers](https://github.com/tc39/proposal-iterator-helpers) to resolve design questions related to concurrency (see below), which are not relevant to sync helpers. Many design questions (including choice of methods) were discussed and decided in that respository, and its readme should be read first.
 
 ## Status
 
@@ -34,9 +34,9 @@ This proposal contains the following methods:
 
 See [proposal-iterator-helpers](https://github.com/tc39/proposal-iterator-helpers) for motivation and additional high-level descriptions for these methods.
 
-## Parallelism
+## Concurrency
 
-In the iterator-producing methods (`.map`, `.filter`, `.take`, `.drop`, and `.flatMap`), async helpers have the opportunity to support _parallelism_. For example, in the following code:
+In the iterator-producing methods (`.map`, `.filter`, `.take`, `.drop`, and `.flatMap`), async helpers have the opportunity to support _concurrency_. For example, in the following code:
 
 ```js
 asyncIteratorOfUrls
@@ -48,11 +48,11 @@ await Promise.all([
 ])
 ```
 
-there could be two calls to `fetch` running at once. For this to work, the helpers have to be explicitly designed to support this. The original design of this proposal instead implemented the helpers as essentially async generators, which buffer calls to `.next` rather than allowing multiple calls to have simulaneous effects.
+there could be two calls to `fetch` running at once. For this to work, the helpers have to be explicitly designed to support this. The original design of this proposal instead implemented the helpers as essentially async generators, which buffer calls to `.next` rather than allowing multiple calls to have simultaneous effects.
 
 This proposal is being revised to support at least the above use case. The exact details of what that looks like for each helper are not yet decided.
 
-### How can I access the new intrinsics?
+## How can I access the new intrinsics?
 
 This proposal introduces two new intrisic objects, in addition to the two added in the sync proposal. They can be accessed as follows: