mlms13

module Main where

import Prelude

import Data.List (List(..), (:), fromFoldable, sortBy, reverse)

data Task = Task String Int

sortTasksByWeightDesc :: List Task -> List Task
sortTasksByWeightDesc = sortBy compareEffort >>> reverse where

mlms13

module AudioDestinationNode = {
  type t;
};

module OscillatorNode = {
  type t;
  
  [@bs.send]
  external connect: (t, AudioDestinationNode.t) => unit = "connect";
};

mlms13

module Measurement = {
  type t =
    | Tsp
    | Tbsp
    | Cup
    | Ounce;
};

module Ingredient = {
  type t = {name: string};

mlms13

module Face = {
  [@deriving (enum, ord, eq)]
  type t =
    | Blank
    | One
    | Two
    | Three
    | Four
    | Five
    | Six

mlms13

// I've seen some examples of how JS promises fail Functor's composition law
// (by hijacking the `then` field of any JS object), making promises not valid
// functors (and by extension, unlawful monads), but I don't recall seeing a
// concise example of Promise breaking Monad's left identity law (though I'm
// sure this has been demonstrated somewhere before).
//
// The key here is that `return a` doesn't behave as expected when `a` is
// already a promise, due to the auto-collapsing nature of promises.

// Left Identity:

mlms13

// This is a useless waste of time. I'm not sure why several years ago
// I thought it would be fun to define digits e.g. type t = Zero | One | Two | etc
// and then implement Semiring (or at least addition) for that type.
//
// But it didn't take long before I ran into the need to "carry the one"
// and I wasn't sure how to proceed.
//
// So here, several years later, I've distilled the problem down to base 2,
// which constantly requires "carrying the one" when adding. To solve this
// I just pattern-match on all of the relevant cases.