When working on Windows with Docker, Linux, etc, your files should be standardized to LF. This command only needs to be run once:
git config --global core.autocrlf input
When working on Windows with Docker, Linux, etc, your files should be standardized to LF. This command only needs to be run once:
git config --global core.autocrlf input
#!/bin/sh | |
TIMEOUT=15 | |
QUIET=0 | |
echoerr() { | |
if [ "$QUIET" -ne 1 ]; then printf "%s\n" "$*" 1>&2; fi | |
} | |
usage() { |
#!/bin/sh | |
# Wait for a file to exist | |
# Modeled off this script | |
# https://gist.github.com/gregberns/7e1254209860632f7a1bf9aa7c7638ee | |
TIMEOUT=15 | |
QUIET=0 | |
echoerr() { |
Type this into Github Gist Search (https://gist.github.com/)
user:BoQsc your search query
(* | |
Below is OCaml code that defines an AST (based on an ML style language) and does two things: | |
* Takes the AST and prints it as a string | |
* Evaluates the AST expressions down where possible | |
Tests cover most of the functionality and some glaring edge cases | |
Note: I couldn't figure out how importing libraries worked (ounit), so I just wrote a custom assert function | |
Run it: |
-- This code doesn't work... | |
-- How can you make a multi-parameter data type be Foldable? | |
-- foldMap over `a` so it can be converted to a Monoid | |
data BinaryTree3 a v | |
= Node3 a (BinaryTree3 a v) (BinaryTree3 a v) | |
| Leaf3 a v | |
deriving (Show) | |
instance Foldable (BinaryTree3 a) where |
-- duplicate $ ListZipper (2:.1:.Nil) 3 (4:.5:.Nil) | |
-- [[1] >2< [3,4,5],[] >1< [2,3,4,5]] >[2,1] >3< [4,5]< [[3,2,1] >4< [5],[4,3,2,1] >5< []] | |
-- data ListZipper a = ListZipper [a] a [a] | |
duplicate :: ListZipper a -> ListZipper (ListZipper a) | |
duplicate z@(ListZipper l i r) = | |
let moveLeft (x :. xs) i rs = ListZipper xs x (i :. rs) :. moveLeft xs x (i :. rs) | |
moveLeft Nil _ _ = Nil | |
moveRight ls i (x :. xs) = ListZipper (i :. ls) x xs :. moveRight (i :. ls) x xs | |
moveRight _ _ Nil = Nil |
data BinaryTree3 v a | |
= Node3 v a (BinaryTree3 v a) (BinaryTree3 v a) | |
| Leaf3 v a | |
deriving (Show) | |
-- Node3 (Node3 0 False (Node3 1 False (Leaf3 3 False) (Leaf3 4 False)) (Leaf3 2 True)) False | |
-- (Node3 (Node3 1 False (Leaf3 3 False) (Leaf3 4 False)) False | |
-- (Leaf3 (Leaf3 3 False) False) | |
-- (Leaf3 (Leaf3 4 False) False)) | |
-- (Leaf3 (Leaf3 2 True) True) |
compose :: | |
Lens b c -> | |
Lens a b -> | |
Lens a c | |
compose (Lens g) (Lens f) = | |
Lens | |
( \a -> | |
let Store s2 g2 = f a | |
Store s3 g3 = g g2 | |
in Store (s2 . s3) g3 |
Yoneda (and its duel Coyoneda) is well known in the Category Theory field and has been ported over to functional languages such as Haskell. Each have their uses - sometimes in similar scenarios, also in very different ways.
This will be a newbie's explanation of the concept, using Haskell to illustrate, without any Category Theory.
From what I've read, the Yonedas are not 'daily-drivers' (not used everyday), but rather can be pulled out when the time is right.
Uses: Both Yoneda's can be used to help speed up a program where there are many fmap
with long lists or big trees involved. Coyoneda can be used if you want to create an 'interface' and build up calculations, then pass those calculations to an 'executor' to run them.