frgomes

Finch: A Life Without Exceptions

Historically, Finch's error handling machinery was built on a very simple yet silly idea that an Endpoint may return a failed Future (i.e., Future.exception). While that doesn't really promote a purely functional approach to error handling (i.e., treat errors as values), it enables quite a few handy setups, including:

• embedding 3rd-party Finagle clients (that may fail) within endpoints w/o extra boilerplate
• simple/minimal required endpoints (i.e., body, param, etc) that return A, not Try[A] nor Either[Error, A]

However this part of Finch's design was heavily influenced by Finagle itself (w.r.t. embedding all of its failures in Future.exception), nothing stops us from revisiting this trade-off and possibly discussing paths forward more idiomatic error handling.

Implicit Errors vs. Explicit Errors

frgomes

The [Future Finch][1] writeup defines a vector in which Finch 1.0 should be developed. The goal for 1.0 is to build very clean, simple, well-tested and composable core based on purely functional constructs and immutable data. The core will provide a solid ground for the micro-frameworks, which should land in Finch 2.0.

This document consists of two parts. The first part presents a high-level picture of Finch 1.0. The second part describes required steps we, Finch contributors and maintainers, have to make in order to bring the library to its first stable version.

One Abstraction to Rule Them All

Looking at the current API, one can find a slight correlation between Routers and RequestReaders. They both take a request and produces a value of type A from it. They both functions: HttpRequest => A. Keeping that in mind, [the idea of composing them ][2] into a single thing (perhaps Router) has found its supporters. The next reasonable step would be to completely merge those abstractions into a sing

frgomes

Advanced Functional Programming with Scala - Notes

Copyright © 2017 Fantasyland Institute of Learning. All rights reserved.

1. Mastering Functions

A function is a mapping from one set, called a domain, to another set, called the codomain. A function associates every element in the domain with exactly one element in the codomain. In Scala, both domain and codomain are types.

val square : Int => Int = x => x * x

frgomes

package example.statemachine

import scalaz.{State, Scalaz}, Scalaz._

object FSM {
  def apply[I, S](f: PartialFunction[(I, S), S]): FSM[I, S] =
    new FSM((i, s) => f.applyOrElse((i, s), (_: (I, S)) => s))

  private def states[S, O](xs: List[State[S, O]]): State[S, List[O]] =
    xs.sequence[({type λ[α]=State[S, α]})#λ, O]