eulerfx

type Service<'Input, 'Output> = 'Input -> Async<'Output>

/// A filter is an aspect in the AOP sense.
type Filter<'Input, 'InputInner, 'OutputInner, 'Output> = 'Input-> Service<'InputInner, 'OutputInner> -> Async<'Output>

type Filter<'Input, 'Output> = 'Input-> Service<'Input, 'Output> -> Async<'Output>

type Continuation<'a,'r> = ('a  -> 'r) -> 'r

module Continuation =     

antonioj-mattos

Keybase proof

I hereby claim:

• I am antonioj-mattos on github.
• I am antoniojm (https://keybase.io/antoniojm) on keybase.
• I have a public key whose fingerprint is AAF9 54B5 B2B1 6C7C 4DCB F26D FB2D A591 4C17 975B

To claim this, I am signing this object:

bryanedds

namespace Marvel
open System
open System.Diagnostics
open System.Threading
open System.Threading.Tasks
open Marvel

/// The 'Vsync' (AKA, 'Variable Synchrony') monad.
/// Runs code synchronously when the 'Venom/System/Sync' Consul variable is 'True', in parallel otherwise.
/// NOTE: to reference how all this stuff works in F#, see here - https://msdn.microsoft.com/en-us/library/dd233182.aspx

gwillem

# Add this snippet to the top of your playbook. 
# It will install python2 if missing (but checks first so no expensive repeated apt updates)
# [email protected]

- hosts: all
  gather_facts: False
  
  tasks:
  - name: install python 2
    raw: test -e /usr/bin/python || (apt -y update && apt install -y python-minimal)

quelgar

Every Argument for Static Typing Applies to Typed Errors

Think of all the arguments you've heard as to why static typing is desirable — every single one of those arguments applies equally well to using types to represent error conditions.

An odd thing I’ve observed about the Scala community is how many of its members believe that a) a language with a sophisticated static type system is very valuable; and b) that using types for error handling is basically a waste of time. If static types are useful—and if you like Scala, presumably you think they are—then using them to represent error conditions is also useful.

Here's a little secret of functional programming: errors aren't some special thing that operate under a different set of rules to everything else. Yes, there are a set of common patterns we group under the loose heading "error handling", but fundamentally we're just dealing with more values. Values that can have types associated with them. There's absolutely no reason why the benefits of static ty

debasishg

Algebraic Domain Modeling

When we talk about the algebra of an operation, we talk about the signature of the operation, and how, starting from the input, we can just "follow the types" to lead to the implementation of that operation.

Consider the following operation generateTrades as part of a domain service TradingService. The idea is to generate all trades that happened on the day (input to the operation) and executed by the user (input to the operation) in the back-office of a securities trading organization.

In the example below, note the following 2 principles that form the core of the algebraic modeling:

1. The sequence of steps mentioned in the specification of the method as comments and correspond one-to-one to the types of the operations used in implementing generateTrades. I have annotated the steps in the implementation below.
2. The implementation of generateTrades is completely decoupled from the implementation of the operations like queryExecutionsForDate, `getAccountNoF