You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Instantly share code, notes, and snippets.
Richard Gomes
frgomes
Fascinated about Computer Science, Finance and Statistics.
Simple Encoding of a purely functional Finite State Machine using Scala and scalaz
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
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
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.