Update AsyncSeq.fsx

Author: dsyme

docs/AsyncSeq.fsx

@@ -17,6 +17,8 @@
 
 # F# Async: FSharp.Control.AsyncSeq
 
+> NOTE: There is also the option to use [FSharp.Control.TaskSeq](https://github.com/fsprojects/FSharp.Control.TaskSeq) which has a very similar usage model.
+
 An AsyncSeq is a sequence in which individual elements are retrieved using an `Async` computation.
 It is similar to `seq<'a>` in that subsequent elements are pulled on-demand.
 `AsyncSeq` also bears similarity to `IObservable<'a>` with the former being based on an "asynchronous pull" and the
@@ -30,15 +32,13 @@ The `AsyncSeq` type is located in the `FSharp.Control.AsyncSeq.dll` assembly whi
 #r "../../../bin/FSharp.Control.AsyncSeq.dll"
 open FSharp.Control
 
-
-
 (**
 ### Generating asynchronous sequences
 
-An `AsyncSeq<'a>` can be generated using computation expression syntax much like `seq<'a>`:
+An `AsyncSeq<'T>` can be generated using computation expression syntax much like `seq<'T>`:
 *)
 
-let asyncS = asyncSeq {
+let async12 = asyncSeq {
   yield 1
   yield 2
 }
@@ -123,19 +123,19 @@ composed using familiar operations on sequences. Furthermore, it will be execute
 *)
 
 (**
-### Comparison with seq<'a>
+### Comparison with seq<'T>
 
-The central difference between `seq<'a>` and `AsyncSeq<'a>` can be illustrated by introducing the notion of time.
+The central difference between `seq<'T>` and `AsyncSeq<'T>` can be illustrated by introducing the notion of time.
 Suppose that generating subsequent elements of a sequence requires an IO-bound operation. Invoking long 
-running IO-bound operations from within a `seq<'a>` will *block* the thread which calls `MoveNext` on the 
+running IO-bound operations from within a `seq<'T>` will *block* the thread which calls `MoveNext` on the 
 corresponding `IEnumerator`. An `AsyncSeq` on the other hand can use facilities provided by the F# `Async` type to make 
 more efficient use of system resources.
 *)
 
 let withTime = seq {
-  System.Threading.Thread.Sleep(1000) // calling thread will block
+  Thread.Sleep(1000) // calling thread will block
   yield 1
-  System.Threading.Thread.Sleep(1000) // calling thread will block
+  Thread.Sleep(1000) // calling thread will block
   yield 1
 }
 
@@ -151,22 +151,19 @@ When the asynchronous sequence `withTime'` is iterated, the calls to `Async.Slee
 the *continuation* of the sequence will be scheduled by `Async` while the calling thread will be free to perform other work. 
 Overall, a `seq<'a>` can be viewed as a special case of an `AsyncSeq<'a>` where subsequent elements are retrieved
 in a blocking manner.
-*)
 
+### Comparison with IObservable<'T>
 
-(**
-### Comparison with IObservable<'a>
-
-Both `IObservable<'a>` and `AsyncSeq<'a>` represent collections of items and both provide similar operations
+Both `IObservable<'T>` and `AsyncSeq<'T>` represent collections of items and both provide similar operations
 for transformation and composition. The central difference between the two is that the former uses a *synchronous push*
 to a subscriber and the latter uses an *asynchronous pull* by a consumer. 
-Consumers of an `IObservable<'a>` *subscribe* to receive notifications about
-new items or the end of the sequence. By contrast, consumers of an `AsyncSeq<'a>` *asynchronously retrieve* subsequent items on their own
+Consumers of an `IObservable<'T>` *subscribe* to receive notifications about
+new items or the end of the sequence. By contrast, consumers of an `AsyncSeq<'T>` *asynchronously retrieve* subsequent items on their own
 terms. Some domains are more naturally modeled with one or the other, however it is less clear which is a more
 suitable tool for a specific task. In many cases, a combination of the two provides the optimal solution and 
 restricting yourself to one, while simplifying the programming model, can lead one to view all problems as a nail.
 
-A more specific difference between the two is that `IObservable<'a>` subscribers have the basic type `'a -> unit` 
+A more specific difference between the two is that `IObservable<'T>` subscribers have the basic type `'T -> unit` 
 and are therefore inherently synchronous and imperative. The observer can certainly make a blocking call, but this 
 can defeat the purpose of the observable sequence all together. Alternatively, the observer can spawn an operation, but
 this can break composition because one can no longer rely on the observer returning to determine that it has 
@@ -177,7 +174,7 @@ To illustrate, let's try to implement the above Tweet retrieval, filtering and s
 Suppose we already have an observable sequence representing tweets `IObservable<Tweet>` and we simply wish 
 to filter it and store the resulting tweets. The function `Observable.filter` allows one to filter observable
 sequences based on a predicate, however in this case it doesn't quite cut it because the predicate passed to it must
-be synchronous `'a -> bool`:
+be synchronous `'T -> bool`:
 *)
 
 open System
@@ -190,8 +187,8 @@ let filteredTweetsObs =
   |> Observable.filter (filterTweet >> Async.RunSynchronously) // blocking IO-call!
 
 (**
-To remedy the blocking IO-call we can better adapt the filtering function to the `IObservable<'a>` model. A value
-of type `Async<'a>` can be modeled as an `IObservable<'a>` with one element. Suppose that we have 
+To remedy the blocking IO-call we can better adapt the filtering function to the `IObservable<'T>` model. A value
+of type `Async<'T>` can be modeled as an `IObservable<'T>` with one element. Suppose that we have 
 `Tweet -> IObservable<bool>`. We can define a few helper operators on observables to allow filtering using
 an asynchronous predicate as follows:
 *)
@@ -262,13 +259,10 @@ notifications must be pushed immediately without delay.
 
 Upon closer inspection, the consumption approaches between the two models aren't all too different. While `AsyncSeq` is based on an asynchronous-pull operation,
 it is usually consumed using an operator such as `AsyncSeq.iterAsync` as shown above. This is a function of type 
-`('a -> Async<unit>) -> AsyncSeq<'a> -> Async<unit>` where the first argument is a function `'a -> Async<unit>` which performs 
+`('T -> Async<unit>) -> AsyncSeq<'T> -> Async<unit>` where the first argument is a function `'T -> Async<unit>` which performs 
 some work on an item of the sequence and is applied repeatedly to subsequent items. In a sense, `iterAsync` *pushes* values to this 
 function. The primary difference from observers of observable sequences is the return type `Async<unit>` rather than simply `unit`.
-*)
 
-
-(**
 ### Performance Considerations
 
 While an asynchronous computation obviates the need to block an OS thread for the duration of an operation, it isn't always the case
@@ -277,10 +271,6 @@ non-blocking operation, it simply allows for it. Also of note is that unlike cal
 an item from an asynchronous sequence requires several allocations. Usually this is greatly outweighed by the
 benefits, it can make a difference in some scenarios.
 
-*)
-
-
-(**
 ## Related Articles
 
  * [Programming with F# asynchronous sequences](http://tomasp.net/blog/async-sequences.aspx/)