View sieve.fs
module FastSieve =
let rec setNonPrimes (isNonPrimes : _ []) step i =
if i < isNonPrimes.Length then
isNonPrimes.[i] <- true
setNonPrimes isNonPrimes step (i + step)
let rec scan (isNonPrimes : _ []) i =
if i < isNonPrimes.Length then
if isNonPrimes.[i] then
scan isNonPrimes (i + 1)
View ConcatTree.fs
module MutableStack =
type Stack<'T> (size :int ) =
let mutable vs : 'T [] = Array.zeroCreate size
let mutable last = -1
member x.IsEmpty = last < 0
member x.IsNotEmpty = last >= 0
View FingerTree.fs
#nowarn "25"
module Reference =
type Node<'T> =
| Node2 of 'T*'T
| Node3 of 'T*'T*'T
type Digit<'T> =
| Digit1 of 'T
| Digit2 of 'T*'T
| Digit3 of 'T*'T*'T
View effectful.fs
module Effective =
open System
type [<Struct>] Continuation<'T> = Continuation of ('T -> unit)
type [<Struct>] Result<'T> =
| Immediate of v:'T
| Delayed of f:(Continuation<'T> -> Continuation<exn> -> unit)
type [<Struct>] Effect<'T, 'U> = Effect of ('T -> Result<'U>)

Thinking about Async/Await

A couple of weeks ago I listened to .Net Rocks! #1433 about Visual Studio 17 with Kathleen Dollard. A very good episode interest but with stuck with me was Kathleen's comment that after all these years she sees very smart people still struggle with async. This is my and others experience as well.

A few years ago I wrote a blog post on why I thought async in C# isn't that great. I took it down a bit later even though it was popular it was also divisive and my understanding of async had grown which made me want to rewrite the whole piece into something better and less divisive.

I used to think that the implicit coupling in async to the SynchronizationContext is a major problem for async but today I think that it's a minor problem for most developers. The reason is that if you are writing ASP.NET you will always have the ASP.NET SynchronizationContext and that gives particular but consistent async behavior. If y

View any_transformer.scala
import ScalaTransformer.AnyTransformer
object ScalaTransformer {
import scala.collection.mutable.ArrayBuffer
sealed abstract class PathElement
object PathElement {
case class Property (name : String) extends PathElement
case class Index (index: Int) extends PathElement
case class Named (name : String) extends PathElement

Transformer combinators

I was considering the excerise and reworked it into that an account holds a bag of properties. The simplest approach is to use a map:

case class Account(props: Map<String, Any>)

However, this can be improved somewhat by introducing typed properties:

View transformer.ts
namespace AnyTransformer {
export interface Cons<T> {
kind: "Cons"
head: T
tail: ImmutableList<T>
export interface Empty {
kind: "Empty"
View transformer.fs
module AnyTransformer =
type [<AbstractClass>] BadCause () =
abstract Describe : string
override x.ToString () = x.Describe
type [<Sealed>] MessageBadCause (msg: string) =
inherit BadCause ()
View gen.fs
module FsGen =
module Details =
let inline adapt f = OptimizedClosures.FSharpFunc<_, _, _>.Adapt f
open System
open Details
type [<Struct>] StdGen = StdGen of int*int
module Random =