[haskell] 변경 가능성이 다분한 부분을 다루자 -02

출처 : 하스켈로 배우는 함수형 프로그래밍

변경 가능성이 다분한 부분을 하스켈로 다뤄보자.

하스켈에서는 비지터 패턴을 사용하지 않는다.

1. 표현식의 형태를 정의하자.

-- 식
data Expr a = Plus (Expr a) (Expr a)  -- 덧셈의 식
            | Square (Expr a)         -- 제곱의 식
            | Number a                -- 숫자의 식

위 내용으로 식에 대한 정의는 끝났다.

2. 이제 처리방식 기술하자.

-- 식의 평가를 실시하는 함수
evalExpr :: Expr Int -> Int
evalExpr (Plus e1 e2) = evalExpr e1 + evalExpr e2
evalExpr (Square e)   = evalExpr e ^ (2 :: Int)
evalExpr (Number n)   = n

-- 식을 문자열로 하는 함수
showExpr :: Expr Int -> String
showExpr (Plus e1 e2) = showExpr e1 ++ " + " ++ showExpr e2
showExpr (Square e)   = "(" ++ showExpr e ++ ")^2"
showExpr (Number n)   = show n

이것도 이렇게 끝났다. 간단하다.

3. 실행하자

main :: IO ()
main = do
  -- e = 1 + (2 + 3)^2
  let e = Plus (Number 1) (Square (Plus (Number 2) (Number 3)))
  putStrLn (showExpr e)
  print (evalExpr e)

여기서 수정사항이 생긴다면
- 식의 증가 (뺄셈 추가)
a. data Expr 에 뺄셈을 추가 (ex. Sub (Expr a) (Expr a) )
- 식에 대한 처리 종류 증가 (JSON 변환)
a. 단순히 evalExpr이나 showExpr과 같은 함수 증가

이렇게 전편에서 사용한 자바의 비지터 패턴을 이용한 코드와 수정하는 방식도 다르고, 코드의 양도 다르다. 왜 이렇게 다를까?
서적에서는 "환경의차이"라고 한다. 꼭 이렇게 설명을 안 하더라도 한줄한줄 비교를 해보면 다른 점이 있는데 그것들이
1. 타입을 정의하는 방식의 차이
2. 패턴매칭(타입을 확인하는 방식)의 차이

1. 타입을 정의하는 방식의 차이

하스켈에서는 data라는 키워드로 타입을 생성한다. 특이한 점은 수식의 구조를 그대로 반영할 수 있다는 것이다. 대부분 우리가 만들려는 새로운 타입들은 저마다 구조를 갖고 있다. 하스켈에서는 그 구조를 아주 쉽게 표현할 수 있다. 마치 수학의 수식처럼 말이다. 그래서 "식 := 식 '+' 식 | '('식')'^2 | 숫자 " 와 같은 (BNF로 표현되는 덧셈,제곱,숫자 자체 중 무엇이든 될 수 있는) 구조를 아주 쉽게 만들어 내는 것이다.

자바에서는 타입을 정의한다는 것은 class, interface를 생성한다는 것이다. Visitor패턴에서는 이것들을 좀 더 세련되게 만든다.
식을 만들려면 식이라는 타입을 만들어야 겠다. 그래서 Expr 인터페이스를 만들고 이것을 이용해서 Plus, Square, Number를 구현한다. 그리고 단순히 구현하는 것이 아니라 Visitor를 받기 위한 함수를 생성할 것이다! 그것은 accept함수이다. 그리고 이제 방문하는 녀석들을 이용해서 표현식들을 처리할 것이다.

이 시점에서 Haskell에서는 취급하고 싶은 식의 타입을 만드는데 3로 간단하게 정의하였다.
Java에서는 interface 1개, class 3개 총 4개를 정의하고 각 3개의 class에 3가지의 accept를 구현해야 한다.(물론 이건 별거 아니다.)
이는 분명 동일한 데이터구조를 다루고 있는데도 어떤 언어냐에 따라 구현 비용이 다르다는 것을 뜻한다.

물론 자바에서 Visitor 패턴을 버리고 Expr 클래스 하나를 만들어서 그 안에 다~ 넣을 수 있다. 그렇게 하면 Expr 클래스는 비대하게 커질 수 있고, 식을 확장하기 위해서 사용하는 비용은 점점 커질 것이다.

2. 패턴매칭(타입을 확인하는 방식)의 차이

Visitor 패턴에 의한 설계에서는 Expr인터페이스를 갖는 각 클래스가 각각의 accept 메소드 속에서 각 클래스 전용으로 준비한 Visitor 인터페이스 메소드를 호출함으로써 판별한다.

예를들어, Number 클래스는 Visitor 인터페이스의 number 메소드를 호출해 두는 식으로 처리한다. 그리고 showExpr와 evalExpr에서 대응하는 처리 또한 Show와 Eval이라는 Visitor 인터페이스를 갖는 클래스로서 구현하게 된다.

Show,Eval 클래스의 plus,square,number의 구현내용은 Haskell의 showExpr, evalExpr 함수의 구현과 거의 동일하다는 것을 알 수 있다.

반대로, 본질적으로는 Haskell 수준의 기술 방식으로 끝나겠지만, 본질적인 부분 이외의 기술에 그만큼 불필요한 비용이 발생할 것이다. 컴파일러는 "이 중 어느 것인가"를 전혀 모르는 듯한 언어 사양이므로 이렇게 할 수밖에 없다.

**Visitor 패턴을 버린 다른 설계로서 instanceof와 같은 실행 시의 타입 정보를 사용할 수 있는 언어라면, 패턴 매치를 통해 인스턴스가 어떤 타입(클래스)의 것인지를 판별하는 구현도 가능할 것이다. 그러나 이 경우 수식이 확장될 때, 그 표현식에 대응한 처리의 구현이 어디선가 누락되었다고 해도 검출할 수가 없다.
구현의 누락은 인터페이스의 부재로 인한 컴파일 오류로 감지되므로 Visitor패턴 쪽이 instanceof와 같은 방법보다 안전하다. (솔직히 instanceof로 만들어진 코드를 보면서 신용이 갈리가 있나... if문이 남발 된 코드는 항상 믿을 수 없다.)

[java] 변경 가능성이 다분한 부분을 다루자 -01 (비지터패턴이용하기)

출처 : 하스켈로 배우는 함수형 프로그래밍

비지터 패턴으로 변경 가능성이 높은 부분을 개발해보자.

파싱트리를 만드는 것에 대해서 배운 적은 없다. 제대로 만들어 본 적이 없기 때문에 한 번쯤은 제대로 배워보고 싶은 생각이 드는데 어디서 부터 공부를 해야 할지 아직도 잘 모르겠다.
일단 우리는 산술식을 다양한 방법으로 표현할 것이다. 이 식을 표현식이라고 부르자.
이 표현식으로 쪼개고 쪼개서 토큰화 시키고 그 수식들을 그대로 문자열로 보이도록 하거나, 계산을 해서 답을 내도록 해보자.
표현식은 BNF로 표현했다고 하자.


비지터패턴으로 만들 것이다.

1. 비지터 인터페이스 생성.

interface Visitor {
    R plus(Expr e1, Expr e2); // 덧셈 식을 위한 메소드
    R square(Expr e); // 제곱 식을 위한 메소드
    R number(N n); // 숫자를 위한 메소드
}

2. 표현식 인터페이스 생성 및 구현

interface Expr {
     R accept(Visitor v);

class Plus implements Expr {
    Expr e1;
    Expr e2;
    public Plus(Expr e1, Expr e2) {
        this.e1 = e1;
        this.e2 = e2;
    }
    @Override public  R accept(Visitor v) { return v.plus(e1, e2); }
}

class Square implements Expr {
    Expr e;
    public Square(Expr e) { this.e = e; }
    @Override  public  R accept(Visitor v) { return v.square(e); }
}

class Number implements Expr {
    N n;
    public Number(N n) { this.n = n; }
    @Override  public  R accept(Visitor v) { return v.number(n); }
}

3. 비지터 패턴을 구현

// 식의 평가를 실시하는 Visitor
class Eval implements Visitor {
    @Override
    public Integer plus(Expr e1, Expr e2) {
        return e1.accept(this) + e2.accept(this);
    }

    @Override
    public Integer square(Expr e) {
        Integer x = e.accept(this);
        return x;
    }

    @Override
    public Integer number(Integer n) {
        return n;
    }
}

// 식을 문자열로 하는 Visitor
class Show implements Visitor {
    @Override
    public String plus(Expr e1, Expr e2) {
        return e1.accept(this) + " + " + e2.accept(this);
    }

    @Override
    public String square(Expr e) {
        return "(" + e.accept(this) + ")^2";
    }

    @Override
    public String number(Integer n) {
        return n + "";
    }
}

이제 실행해보자.

public class TestVisitor {
    public static void main(String[] args) {
        //  e = 1 + (2 + 3) ^ 2
        // 실제로는 구문 해석 등에 의해서 좀 더 크고 복잡한 것을 가정
        Expr e = new Plus(new Number(1), new Square(new Plus(new Number(2)
                                                                ,new Number(3))));
        System.out.println(e.accept(new Show()));
        System.out.println(e.accept(new Eval()));
    }
}

이 프로그램과 설계에는 문제가 없음.
변경에 대한 유연성에 대해서도 다음과 같은 경우에 따라 각각 가산해서 대응할 수 있으므로 Visitor 패턴을 사용하는 것은
객체지향 프레임워크로서는 더할 나위 없는 방법이라고 말할 수 있다.
- 식의 증가에 대해 (뺄셈의 추가)
a. Visitor의 메소드를 늘린다.
b. 식의 인터페이스를 계승하는 클래스를 늘린다.
- 식에 대한 처리 종류의 증가에 대해 (JSON으로 변경)
a. Visitor를 계승하는 클래스를 늘린다.

이런식으로 계속 계산식 혹은 처리방식을 추가할 때, 객체지향적인 방법으로 추가를 할 수 있게 된다.

[java]NULL에게서 도망가기 위한 여정 - 01

출처 : 하스켈로 배우는 함수형 프로그래밍

https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare

NullPointerException은 가장 많이 보이고 짜증나는 예외이다.
대부분의 언어에서 null은 아주 흔하게 존재한다.
이 녀석은 대부분 에러를 낼 때만 만나게 되는데 우리는 이 null이 없이는 코딩을 할 수 없을 것 같은 느낌을 가지고 있다.
그 만큼 null은 우리의 코딩방식을 반영한다.
null이라는 건 빈 박스를 취하는 것이다. 무엇을 넣을지는 모르겠지만 일단 취하는 것이다.
그 박스를 제공하기 위해 컴퓨터는 빈 공간을 제공해줄 것이다.

만약 빈 박스에 내용으로 뭔가 하려 한다면? 자바에서는 NullPointerException이 날 것이다.

시대가 조금씩 바뀌고 있다. NULL을 모두 체크해야 하는 것으로는 한계가 있다.
요즘에는 Optional이라는 개념이 많이 유입되고 있는 것 같다.
자바의 경우에도 java.util.Optional 이라는 녀석이 생겼다. 그래서 Optional에서 값이 있는지 없는지를 체크할 수 있도록 한다.
이제 if/else문에 대한 처리를 Optional 내부에서 처리를 할 수 있기 때문에 코드가 복잡할 필요가 없어진다.

package org.test;

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.Optional;
import java.util.function.BiFunction;

public class TestOptional {
 // 공백으로 분할하기, 세 개로 분할할 수 없으면 무효!
 private static Optional words(String expr) {
  String[] res = expr.split(" ");
  if (3 == res.length) {
   return Optional.of(res);
  }
  else {
   return Optional.empty();
  }
 }
 
 // 문자열을 정수로 변환, 변활할 수 없으면 무효
 private static Optional toNum(String s) {
  try {
   return Optional.of(Integer.parseInt(s));
  } catch (NumberFormatException ex) {
   return Optional.empty();
  }
 }
 
 private static Optional add(Integer a, Integer b) {
  return Optional.of(a + b);
 }
 private static Optional sub(Integer a, Integer b) {
  return Optional.of(a - b);
 }
 private static Optional mul(Integer a, Integer b) {
  return Optional.of(a * b);
 }
 private static Optional div(Integer a, Integer b) {
  if (a != b) {
   return Optional.of(a / b);
  }
  else  {
   return Optional.empty();
  }
 }
 
 // +-*/ 외 문자 무효
 private static Optional>> toBinOp(String s) {
  switch(s) {
   case "+" : return Optional.of(TestOptional::add);
   case "-" : return Optional.of(TestOptional::sub);
   case "*" : return Optional.of(TestOptional::mul);
   case "/" : return Optional.of(TestOptional::div);
   default : return Optional.empty();
  }
 }

 public static void main(String[] args) throws IOException {
  
  String expr = new BufferedReader(new InputStreamReader(System.in)).readLine();
  
  // 마치 haskell의 Monad같은 모습.
  System.out.println(
   words(expr)
    .flatMap(ss -> toNum(ss[0])
     .flatMap(a -> toBinOp(ss[1])
      .flatMap(op -> toNum(ss[2])
       .flatMap(b -> op.apply(a, b)))))
    .map(n -> "" + n)
    .orElseGet(() -> "invalid"));   
  }
 }
}

여기서 flatMap이 뭔가 하면 Optional을 받아서 Optional을 리턴하는 녀석인데, Optional의 내용이 empty()면 다음 flatMap으로 전파되지 않는다.
예를들어보자.

Optional str = Optional.ofNullable("AB");
//Optional str = Optional.ofNullable("ABC");
//Optional str = Optional.ofNullable("ABCD");
str.flatMap(ss -> {
 if (ss.length() > 3) {System.out.println("FlatMap1 fail");return Optional.empty();}
 else {System.out.println("flatMap1 pass");  return Optional.of(ss.toLowerCase());}
}).flatMap(ss2 -> {
 if (ss2.length() > 4) {System.out.println("FlatMap2 fail"); return Optional.empty();}
 else {System.out.println("FlatMap2 pass");return Optional.of(ss2.toUpperCase() + "@#$");}
}).ifPresent(System.out::println);

저 위에 있는 것들로 테스트를 해보면 empty()를 뱉는 순간 다음 내용으로 if-else문으로 이어지지 않음을 알 수 있다.

여기서 알아야 할 점은
NULL 체크를 flatMap에서 전부한다는 것이다. 그런데 온통 flatMap이 있으니!
NULL 체크를 모든 곳에서 하는 것이다.
왜 flatMap이 계속 함수 내부로 형성되는지 의아할 것이다.
각 토큰을 Optional로 리턴한 OPtional 값을 하나하나 검사하려고 flatMap을 사용하는 것이다.
그리고 첫번째 flatMap의 값 ss를 함께 사용하려는 의도도 있을 것이다.

게다가 마지막으로 flatMap은 인스턴스 메소드다. 무슨 말이냐면 객체에서 불러내야 사용할 수 있는 것이다.
Optional 객체가 있을 때, 그 객체에서 flatMap 메소드를 호출해야 가능하다. 그러므로 Optional값이 하나 나오면
그때 검사하고 다른 Optional값이 나오면 또 검사할 flatMap을 그때그때(전부) 호출한다.

이제 이 내용을 하스켈로 보자.
http://www.whynam.com/2018/08/haskell-null-02.html

[haskell] NULL에게서 도망가기 위한 여정 - 02

출처 : 하스켈로 배우는 함수형 프로그래밍

NULL에게서 도망가기 위한 여정 - 02

- 행간에 처리를 발생시킬 수 있는 힘

이전에는 java.util.Optional을 만나서 NULL에게서 좀 멀어진 느낌을 받았다.
하지만 (책에서는) 개별 인스턴스(객체)에 대한 실패를 동일 문맥상에서 취급할 수 없는 문제를 해결할 수 없었다.
* 결국 객체가 생성될 때마다 context(문맥)이 계속 생성되고 안으로 파고 들어간다.

하스켈을 봐보자.

-- Optional.hs
-- $ stack ghc Optional.hs
-- Optiona.exe
-- 1 + 1
-- Optiona.exe
-- 4 / 0

-- 문자열을 정수로 변환. 변환할 수 없다면 무효
toNum :: String -> Maybe Int
toNum s = case reads s of
        [(n,"")] -> Just n  -- 저절로 변환됨.
        _        -> Nothing

-- 사칙연산. 연산할 수 없다면 무효
addOp :: Int -> Int -> Maybe Int
addOp a b = Just (a + b)
subOp :: Int -> Int -> Maybe Int
subOp a b = Just (a - b)
mulOp :: Int -> Int -> Maybe Int
mulOp a b = Just (a * b)
divOp :: Int -> Int -> Maybe Int
divOp _ 0 = Nothing
divOp a b = Just (a `div` b)

-- +-*/ 연산 변환, 나머지 무효
toBinOp :: String -> Maybe (Int -> Int -> Maybe Int)
toBinOp "+" = Just addOp
toBinOp "-" = Just subOp
toBinOp "*" = Just mulOp
toBinOp "/" = Just divOp

eval :: String -> Maybe Int
eval expr = do
  -- 스페이스로 분할
  let [sa, sop, sb] = words expr
  
  a <- toNum sa     -- 문자열을 숫자로
  op <- toBinOp sop -- 문자열을 연산자로 
  b <- toNum sb     -- 문자열을 숫자로
  a `op` b          -- 연산
  
main :: IO ()
main = getLine >>= putStrLn . maybe "invalid" show . eval

일단 >>= 는 바인드라고 불리는데 getLine으로 받은 값을 바로 다음 타자에게 넘겨준다고 생각하면 된다. (여기선 그냥 이렇게 넘어가자)
putStrLn . maybe "invalid" show . eval
위 녀석이 뭔지 궁금할 것이다.
한번 타입을 보자.

Main> :t eval
eval :: String -> Maybe Int

Main> :t show
show :: Show a => a -> String

Main> :t show . eval
show . eval :: String -> String

Main> :t maybe
maybe :: b -> (a -> b) -> Maybe a -> b

Main> :t maybe "invalid" show . eval
maybe "invalid" show . eval :: String -> [Char]

자 보자.
eval은 String을 받아서Maybe Int를 리턴한다.
show는 아무거나 받아서 String을 내뱉는다.
show . eval 은 String을 받아서 String을 뱉는다. 이게 합성의 힘이다. 중간에 뭐가 있던 단순해지는 것이다.

maybe 함수는 디폴트값, 함수, Maybe 값을 받는다. Maybe값을 받아서 그 값의 내용물을 빼내서 함수를 적용시키고 리턴한다.
만약 Maybe값이 Nothing이라면 디폴트값을 내뱉는다. (Maybe 타입생성자를 없애버리는 역할인듯)

Main> eval "1 + 1"
Just 2

Main> (show . eval) "1 + 1"
"Just 2"

Main> (maybe "invalid" show . eval) "1 + 1"
"2"

Main> putStrLn $ (maybe "invalid" show . eval) "1 + 1"
2

Main> let a = putStrLn . maybe "invalid" show . eval
Main> a "1 + 1"
2

좋다 이렇게 합성이 되는 것이다.

좀 더 설명해보자면,
Haskell에서 Maybe라는 것은 java.util.Optional같은 것과 동일한 문제를 해결하기 위해 있다.
Nothing이 무효, Just가 유효값이다.

만약 앞에 처리에서 Nothing이 발생하면 이후 처리는 실행되지 않고 최정 결과도 Nothing이 된다.
자바의 Optional과 아주 비슷하지만 자바처럼 각각의 인스턴스에 하나하나 flatMap으로 덮어야 하는 수고가 필요없이
아주 그런 걸 신경쓰지 않고 코딩을 하듯 만들어졌다.

무효값이 되었을 경우 건너뛰는 코드 같은건 보이지 않는다.
(책의 내용을 빌리자면, 마치 원래 무효가 될지도 모른다는 생각조차 무시하고 작성된 것같이 보인다)

이것은 Haskell이 갖는 "문맥을 프로그래밍할 수 있는 힘 (monad의 do)"을 이용하고 있기 때문이라고 책은 설명한다.

문맥이란 문장과 문장 사이에서 이루어지는 무언가를 말한다. 자바에서 문장 끝에 붙는 ";"에 무언가 처리를 실시하고 있는 것과 같다.

Maybe는 그러한 "문맥"을 프로그래밍의 한 예 중 하나다.
Maybe가 갖는 문맥이란,

"이전 처리가 무효가 되었다면 그 이후도 모두 무효, 그렇지 않으면 정상 처리를 계속한다" 라는 것이다.
java.util.Optional처럼 인스턴스에 포함시킨 기능이 아니라 문맥에 포함시킨 기능이므로 각 값에 의존한 코딩을 하지 않아도 된다.
(대체 문맥에 포함시킨 기능이라는 것... 이런건 어떻게 프로그래밍하는 것 일까? 이런걸 가지고 놀 때가 언제일지)

[haskell] 함수를 이용한 개발-03

출처 : 하스켈로 배우는 함수형 프로그래밍

함수를 이용한 개발

- 알맞는 부분을 만들거나 알맞은 부품만 맞추는 능력

아래 소스는 책에 있는 내용을 거의 그대로 베낀 것이다.
한가지 바뀐 점은 타입을 생성하고 사용하지 않는 부분이 있어서 그 부분만 치환했으나 중요한 부분은 아니다.

-- Coord.hs
-- $runghc Coord.hs

import Text.Printf

-- 좌표의 타입
type Coord = (Double, Double)

-- 좌표 변환 설정
data Config = Config { rotAt :: Coord            -- 회전 중심 좌표
                     , theta :: Double           -- 회전량[라디안]
                     , ofs   :: (Double, Double) -- 병행 이동량
                     }

-- 좌표 변환 함수의 타입은 "좌표를 별도의 좌표로 이동"하는 함수
-- "좌표를 받아서 좌표를 뱉는 함수"타입
type CoordConverter = Coord -> Coord

-- 병행 이동의 프리미티브
trans :: Coord -> CoordConverter
trans (dx, dy) = \(x, y) -> (x+dx, y+dy)

--회전의 프리미티브
rotate :: Double -> CoordConverter
rotate t = \(x, y) -> (cos t * x - sin t * y, sin t * x + cos t * y)

-- 설정을 베이스로 한 병행 이동
transByConfig :: Config -> CoordConverter
transByConfig config = trans (ofs config)

-- 설정을 베이스로 한 회전
rotateByconfig :: Config -> CoordConverter
rotateByconfig config = postTrans . rotate (theta config) . preTrans 
    where rotateAt = rotAt config
          preTrans = trans(rotate pi $ rotateAt)
          postTrans = trans rotateAt

convertByConfig :: Config -> CoordConverter
convertByConfig config = transByConfig config . rotateByconfig config

main :: IO ()
main = do
  let config = Config { rotAt = (0.5, 0.5), theta = pi / 4, ofs = (-0.5, -0.5)}
  let unitRect = [(0,0),(0,1),(1,1),(1,0)]
  
  let convertedRect = map (convertByConfig config) unitRect
  mapM_ (uncurry $ printf "(%.6f, %.6f)\n") convertedRect
  -- mapM_ is useful for executing something only for its side effects.
  -- https://stackoverflow.com/questions/27609062/what-is-the-difference-between-mapm-and-mapm-in-haskell

하스켈에서는 (.) 을 이용해서 함수를 합성한다.

Prelude> let a = (*2) . length
Prelude> a [1,2,3,4]
8

이 형태는 수학적인 표기법과 아주 비슷하다.

또한 javascript에서 compose는 일단 함수끼리 합성을 시켰을 때, 제대로된 타입들로 합성이 된건지 알 수가 없다.
정말 g의 치역과 f의 정의역이 연결되는지 (g의 리턴타입과 f의 인풋타입이 잘 맞는지) 알 수가 없다.
실행 시에 함수를 만들 수 있으므로 실행 시에 만든 함수들끼리 합성할 수 있는지의 여부를 테스트 등을 통해서 직접 봐야 알 수 있다.

한편 Haskell은 타입 검사가 자체적으로 존재하므로 합성 가능 여부가 타입에 따라 결정된다.

여기서 중요하게 봐야 할 곳은 CoordConverter 같다. CoorConverter는 Coord를 받아서 Coord를 리턴하는 함수를 말한다.
CoordConverter타입인 함수들은 서로 결합이 쉽다.
왜냐하면 Coord가 정의역이고 Coord가 치역이기 때문에 서로 잘 맞는다. (합성을 해도 무난하다)

하스켈에서 uncurry는 curry된 녀석들을 다시 풀어버린다고 생각하면 된다.
(즉 내용을 한 번에 받는 함수가 된다. 하지만 하스켈은 기본적으로 curried function 이기 때문에 튜플로 한번에 받게 된다.)
curry는 그 반대이다. 함수를 일단 커리하여 받을 수 있는 함수로 바꿔버린다.

Prelude> curry fst 1 2
1
Prelude> :t curry
curry :: ((a, b) -> c) -> a -> b -> c
Prelude> :t fst
fst :: (a, b) -> a
Prelude> :t curry fst
curry fst :: c -> b -> c
Prelude> curry fst
error!!
Prelude> curry fst 1 2
1

하스켈에서 uncurry는 curry된 녀석들을 다시 풀어버린다고 생각하면 된다.

Prelude> :t uncurry
uncurry :: (a -> b -> c) -> (a, b) -> c
Prelude> :t (+)
(+) :: Num a => a -> a -> a
Prelude> :t uncurry (+)
uncurry (+) :: Num c => (c, c) -> c
Prelude> (+) 1 2
3
Prelude> uncurry 1 2
error!!
Prelude> uncurry (+) (1, 2)
3

[javascript] 함수를 이용한 개발-02

출처 : 하스켈로 배우는 함수형 프로그래밍

함수를 이용한 개발

- 함수의 부품화, 그리고 조합(합성)

함수를 좀 더 부품화 할 필요성이 있다고 저자는 생각했었나 보다.
사실 첫번째 소스코드에서 보면 알 듯이 기본적으로 기존의 좌표를 새로운 좌표로 변형해서 리턴하는 것이 목표이다.

config값과 coord(좌표)값을 받으면 new coord 가 리턴되어서 나오는 것이다.
이제 필자는 config와 coord를 분리해야 한다고 한다.

왜냐하면 "무언가(config)와 좌표를 받아 좌표를 반환하는" 함수들을 결합할 경우,
"무언가" 부분을 부여해야 한다는 것이 조합할 때의 표현을 복잡하게 만들기 때문이라고 한다.

즉, 이제 함수를 부품화해서 레고처럼 조합할 껀데, 받아야 하는 것이 2개보다는 1개가 낫다.
뭐 이런 말이려나.

여튼 "좌표(coord)만 받아서 좌표를 반환하는" 함수를 서로 조합한다면 서로 아무리 조합해도
"좌표를 받아서 좌표를 내뱉는 "함수들 이기 때문에 조합이 더 편해질 것이다.

아래 내용은 "무언가(config)와 좌표를 받아 좌표를 반환했던" 함수였던 것에서
"무언가를 받고나서 '좌표를 받아 좌표를 반환하는 함수'를 반환하는 함수"로 변경했다.

일종의 커링을 사용한 것인데 무언가(config)를 좌표(coord)와 분리시키기 위해서
이전에 내가 임의로 붙여봤던 커링을 사용해서 config를 미리 함수 안에 넣어버렸다. 그리고 조합을 할 때는

좌표만을 다루는 함수끼리 조합이 되도록!

// 보다 나은 부품화

function clone(obj) {
  var f = function(){};
  f.prototype = obj;
  return new f;
}


// 함수 합성
function compose (f,g) { return function(x) { return f(g(x)); } };


// 병행 이동의 프리미티브
//var trans = function (dx, dy, coord) {
// var result = clone(coord);
// result.x += dx;
// result.y += dy;
// return result;
//}
var trans = function (dx, dy, coord) {
 return function(coord) {
  var result = clone(coord);
  result.x += dx;
  result.y += dy;
  return result;
 }
}

// 회전 이동의 프리미티브
//var rotate = function (theta, coord) {
// var result = clone(coord);
// result.x = Math.cos(theta) * coord.x - Math.sin(theta) * coord.y;
// result.y = Math.sin(theta) * coord.x + Math.cos(theta) * coord.y;
// return result;
//}
var rotate = function(theta) {
 return function(coord) {
  var result = clone(coord);
  result.x = Math.cos(theta) * coord.x - Math.sin(theta) * coord.y;
  result.y = Math.sin(theta) * coord.x + Math.cos(theta) * coord.y;
  return result;
 }
}

// 설정을 베이스로 한 병행 이동
//var transByConfig = function (config, coord) {
// return trans(config.ofsX, config.ofsY, coord);
//}
var transByConfig = function(config) {
 return trans(config.ofsX, config.ofsY);
}

// 설정을 베이스로 한 회전
//var rotateByConfig = function (config,coord) {
// var preTrans = trans(-config.rotAt.x, -config.rotAt.y, coord);
// var rotated = rotate(config.theta, preTrans);
// var postTrans = trans(config.rotAt.x, config.rotAt.y, rotated);
// return postTrans;
//}
var rotateByConfig = function(config) {
 return compose(trans(config.rotAt.x, config.rotAt.y),
      compose(rotate(config.theta),
        trans(-config.rotAt.x, -config.rotAt.y)));
}

// 설정을 베이스로 한 좌표 변환
//var convertByConfig = function(config, coord) {
// return transByConfig(config, rotateByConfig(config, coord));
//}
var convertByConfig = function(config) {
 return compose(transByConfig(config), rotateByConfig(config));
}


var config = {
 rotAt : { x : 0.5, y : 0.5 }
 , theta : Math.PI / 4
 , ofsX : -0.5
 , ofsY : -0.5
}

var unit_rect = [
{x:0,y:0}, {x:0,y:1}, {x:1,y:1}, {x:1,y:0}
]

// 변환 후의 좌표
//var converted_rect = unit_rect.map(function(coord) { 
// return convertByConfig(config, coord);
//}
// 매개변수가 하나로 변하면서 map에서 바로 만들어진 함수를 지정할 수 있다. 하지만 curry를 이용해서 사용할 수도 있겠다.
var converted_rect = unit_rect.map(convertByConfig(config));

converted_rect.map(function(coord) {
 console.log('(' + coord.x.toFixed(6) + ',' + coord.y.toFixed(6)+')');
}

함수 안에 있는 알고리즘을 보는 것이 아니라. return을 하는 방식이 변경되었고 compose를 이용한 함수합성을 유심히 봐야한다.

[Java] 기본 TLSv1.1 연결 방법

public static void main(String[] args) throws NoSuchAlgorithmException, IOException, KeyManagementException {
 System.out.println("TLS TEST");
 String httpsUrl = "https://stagepg.payletter.com/TLSTest/test.html";
 
 SSLContext sc = SSLContext.getInstance("TLSv1.1");
 sc.init(null, null, new java.security.SecureRandom());
 
 URL url = new URL(httpsUrl);
 HttpsURLConnection connection = (HttpsURLConnection) url.openConnection();
 connection.setSSLSocketFactory(sc.getSocketFactory());
 
 BufferedReader br = null;
 
 br = new BufferedReader(new InputStreamReader(connection.getInputStream(), "EUC-KR"));
 
 String line = "";
 while ((line = br.readLine()) != null){
  System.out.println(line);
 }
 br.close();
}

[javascript] 함수를 이용한 개발-01

출처 : 하스켈로 배우는 함수형 프로그래밍

함수를 이용한 개발

- 맞을지 안 맞을지도 모르는 부품을 만들거나 맞추는 능력

이 코드의 내용은 전적으로 "하스켈로 배우는 함수형 프로그래밍"의 내용을 가져온 것이다. 그곳에서 내가 더한 내용은 소스 맨밑에 currying을 이용한 부분밖에 없다.
해당 내용은 서적을 읽어야 왜 이러한 기술이 중요한 지 알 수 있다.
서적에서는 C언어로는

1. 실행시간에 함수를 생성할 수 없어서 결국 for-loop만을 고집해야 하는 점.
2. 그 작은 차이가 조금씩 코드를 변화하고
3. 결국 개발자의 생각하는 방식마저 변화시킬 것이며
4. 자유를 얻게 될 것이라고 말하는 것 같았다.

해당 소스는 꽤나 단순하다.(??) 그리고 내용을 이해하지 않고 함수들의 구조들이 어떻게 변화되는지만 봐도 흥미롭다.
좌표에 한 점이 있는데 이 점을 dx,dy로 이동시키느냐, 혹은 각도(theta)를 이용해서 회전함으로 좌표를 옮기느냐 하는 것이다. (혹은 둘다)

// 객체 복사용
function clone(obj) {
  var f = function(){};
  f.prototype = obj;
  return new f;
}

// 병행 이동의 프리미티브
var trans = function (dx, dy, coord) {
 var result = clone(coord);
 result.x += dx;
 result.y += dy;
 return result;
}

var rotate = function (theta, coord) {
 var result = clone(coord);
 result.x = Math.cos(theta) * coord.x - Math.sin(theta) * coord.y;
 result.y = Math.sin(theta) * coord.x + Math.cos(theta) * coord.y;
 return result;
}

// 설정을 베이스로 한 병행 이동
var transByConfig = function (config, coord) {
 return trans(config.ofsX, config.ofsY, coord);
}

// 설정을 베이스로 한 회전
var rotateByConfig = function (config,coord) {
 var preTrans = trans(-config.rotAt.x, -config.rotAt.y, coord);
 var rotated = rotate(config.theta, preTrans);
 var postTrans = trans(config.rotAt.x, config.rotAt.y, rotated);
 return postTrans;
}

// 설정을 베이스로 한 좌표 변환
var convertByConfig = function(config, coord) {
 return transByConfig(config, rotateByConfig(config, coord));
}
var config = {
 rotAt : { x : 0.5, y : 0.5 }
 , theta : Math.PI / 4
 , ofsX : -0.5
 , ofsY : -0.5
}

var unit_rect = [
{x:0,y:0}, {x:0,y:1}, {x:1,y:1}, {x:1,y:0}
]

// 여기서 coord가 map으로 연결되서서 계속바뀌고
// config는 그대로 계속 공통으로 쓰게 되는 함수를 콜해서 리턴하는 익명함수를 각각 만들어서 실행한다.
var converted_rect = unit_rect.map(function(coord) { 
 return convertByConfig(config, coord);
});

converted_rect.map(function(coord) {
 console.log('(' + coord.x.toFixed(6) + ',' + coord.y.toFixed(6)+')');
});

/// curry를 사용하면 좀 더 이뻐 보일 수 있겠다.
console.log('====');
var curriedConvertedByConfig = function(coord) {
 return convertByConfig(config, coord);
}
var converted_rect2 = unit_rect.map(curriedConvertedByConfig);
converted_rect2.map(function(coord) {
 console.log('(' + coord.x.toFixed(6) + ',' + coord.y.toFixed(6)+')');
});

위 내용을 html을 하나 생성해서 로드해보자.

다음페이지
http://www.whynam.com/2018/08/javascript-02.html

출처들:
http://adit.io/posts/2013-04-17-functors,_applicatives,_and_monads_in_pictures.html
https://ko.wikipedia.org/wiki/%EB%AA%A8%EB%82%98%EB%93%9C_(%EB%B2%94%EC%A3%BC%EB%A1%A0)
https://ko.wikipedia.org/wiki/%EB%AA%A8%EB%85%B8%EC%9D%B4%EB%93%9C
https://ko.wikipedia.org/wiki/%EB%B2%94%EC%A3%BC%EB%A1%A0
https://en.wikipedia.org/wiki/Monad_(category_theory)
https://en.wikipedia.org/wiki/Monad_(functional_programming)

펑터, 어플리커티브 펑터, 모나드에 대해 공부해보자.

1. 펑터(Functor)란 무엇인가.

박스 안에 당신이 사랑하는 무엇 인가를 가둔다. 박스 안에 있는 물건은 마음대로 변경할 수 없다.

[1]  # [] 가 박스의 형태라고 하자. 
# (어짜피 리스트는 박스의 한 형태이며, 또한 박스처럼 생겼으니 박스라고 하자.)

당신은 박스 안에 1을 넣었다. 나중에 시간이 지나서 이 박스 안에 1에 +1을 하고 싶어졌다고 하자.
당신은 박스 안에 있는 것을 마음대로 빼내서 2로 바꿀 수 없다.
이럴때 필요한 것이 functor이다.

class Functor f where
fmap :: (a -> b) -> f a -> f b

여기서 f는 박스의 형태를 말한다. 위에서 우리는 []가 박스의 한 형태라고 말 한적이 있다.
위에서 a는 당신이 소중하게 여기는 값의 형태이다. 나는 여기에 1 을 넣었으니, Number 일 것이다.

내 박스 안에 값을 더하고 조심스럽게 변화시키고 싶다. 당신은 박스에 내용을 꺼내서 변경할 수 없다.
왜냐하면 그것은 너무 소중해서 바깥 세상에 더럽혀지면 안된다. 대신
박스 안에 함수를 넣는다. 그것이 (a -> b)이다. a형태의 값을 b로 변경하는 함수를 박스 안에 넣는다고 상상해보자.
내가 너무나도 사랑하기에 꺼낼 수는 없지만 변경해야 할 때, 당신은 그 박스 안에 함수를 넣는것이다.

>fmap (+2) [1]
[3]

나는 [1] 에서 1을 꺼내서 2를 더하지는 못했지만, [1] 박스 안에 (+2) 를 넣어서 박스 안에 값을 3으로 바꾼후 박스에 넣어진 채로 리턴받았다.
<$>에 대해서 알아야 할 것이 있는데 <$>는 fmap의 infix버전이라고 보면 된다. (그러니까 줄임말 같은 것인데 infix로 쓰인다는 것)

(+2) <$> [1]
[3]

2. 어플리커티브 펑터

이제 내 안에 있는 박스를 소중하게 변경하는 법을 알았다. 박스안에 값들을 숨기고 (혹은 그 박스 안에 넣어야만 가치있는 값일 지도 모른다. 아니면 효율적인 것일지도) 그 박스 안에 내용들이 더럽혀지지 않도록 하는 것.
그럼으로써 나는 값을 변경하는데 실수하지 않았다는 확신이 들 것이다. 왜냐하면 내가 fmap(펑터)로 박스안에 주입한 함수만이 박스 안의 내용을 변경할 것이니 그것들만 체크하면 되기 때문이다.
(바깥의 내용이 변화를 일으키지 않는다는 확신을 갖게 할 것이다.)

하지만 이렇게 생각해보자. 박스 안에 값들도 중요하지만, 내 소중한 값들을 변경할 녀석(함수)은 중요한 녀석일까 아닐까?
당연히 중요하다.
이녀석들도 박스로 꽁꽁 숨겨서 보관해야할 경우가 있다. 아니면 박스 형태로 올 경우가 있다.
박스 안에 있는 함수를 꺼내서 다른 박스에 넣을 수 있을까? 현재로썬 불가능하다. 그렇기 때문에 펑터를 사용한 것이다. 박스 안에 있는 함수를 꺼낼 수 있다면, 값을 꺼낼 수도 있을 것 아닌가! (왜냐하면 하스켈에서 함수는 값과 별반 다르지 않기 때문에!)
이럴때 어플리커티브 펑터를 이용하는 것이다.
Control.Applicative의 <*>로 가능하게 한다.

>[(+2),(+10)] <*> [10,20,30]
[12,22,32,20,30,40]

앞에 [(+2),(+10)] 는 함수들을 담은 박스다. 이 것을 이용해서 값을 담을 박스 [10,20,30]를 변형시킬 것이다. (아니 변형시키는 것이 아니라 새로 만들어서 리턴하는 것이다.)

다른 예제를 보자.

> (+) <$> [1,2] <*> [10,20,30]
[11,21,31,12,22,32]

<$>는 fmap의 infix버전임을 아까 말했다. <*>는 이제 어플리커티브 펑터라고 보자.
이녀석들은 왼쪽부터 실행된다. 왜냐고?

Prelude> :info <$>
(<$>) :: Functor f => (a -> b) -> f a -> f b
-- Defined in ‘Data.Functor’
infixl 4 <$>

Prelude> :info <*>
class Functor f => Applicative (f :: * -> *) where
...
(<*>) :: f (a -> b) -> f a -> f b
...
-- Defined in ‘GHC.Base’
infixl 4 <*>

infixl 4 <*>, <$> 이 보일 것이다. infix는 중위연산자라는 것이고 그 다음에 붙어있는 l은 left인 것으로 알고 있다. 그러니 left부터 인것이다. (4)는 우선순위이다. 누구먼저 실행되냐인데 둘 다 4 이므로
왼쪽에 있는 녀석이 실행될 것이다.

(+) <$> [1,2] 가 어떻게 실행되는 것인지 보자.

Prelude> :t (+) <$> [1,2]
(+) <$> [1,2] :: Num a => [a -> a]

박스 안에 a -> a 가 들어있다. 함수라는 말이다. 아마 [(+1), (+2)] 가 들어있을 것이다. 하지만 볼 수는 없다. Show가 구현되지 않았기 때문이다.
그렇다면 [(+1),(+2)] <*> [10,20,30]과 같아진다.

이런 일을 한번에 해주는 녀석이 있다.

(<*>) = liftA2 id
liftA2 f x y = f <$> x <*> y

liftA2로 한번 실행해보자.

Prelude> liftA2 (+) [1,2] [10,20,30]
[11,21,31,12,22,32]

3. 모나드

지금까지 무엇을 배웠나 생각해보자.
펑터 : fmap 혹은 <$>, 박스로 보호되고 있는 값에 함수를 주입하여 [박스 안에 새로운 값]을 넣는다.
어플리커티브 펑터 : <*> 혹은 listA2, 박스로 보호되고 있는 값과 함수로 [박스 안에 새로운 값]을 넣는다.


모나드는? 이것들과 별반 다른 것이 없을 것이라고 믿어보자.
(사실 잘 모르겠으며, 만약 이 글을 읽어주는 자비심 많은 독자가 있으시다면, 아래 내용은 저의 의식의 흐름으로 적어간 기록이기 때문에 스킵 하시고 내려가세요. 아래 ==END== 로 )
=========================== START ========================
일단 모나드가 뭐냐? 위키를 봐보자.
https://ko.wikipedia.org/wiki/%EB%AA%A8%EB%82%98%EB%93%9C_(%EB%B2%94%EC%A3%BC%EB%A1%A0)
범주론에서, 모나드는 내부 함자 범주의 모노이드 대상이다.
모노이드란?
https://ko.wikipedia.org/wiki/%EB%AA%A8%EB%85%B8%EC%9D%B4%EB%93%9C
추상대수학에서, 모노이드는 항등원을 갖는, 결합 법칙을 따르는 이항 연산을 갖춘 대수 구조이다.
항등원을 갖고, 결합 법칙을 따르는 이항연산(binary oeprator)을 갖춘 구조인데 항등원은 아무리 연산을 해도 같은 것이고, 결합 법칙은 다르게 결합해도 같은 것을 말한다.
곱하기(*)를 예로들자

15 * 1 = 15 (항등원)
(15 * 2) * 10 = 15 * (2 * 10) (결합법칙)

이런 형태이면 모노이드라고 부르는가 보다.

여기서 범주론은 뭘까?
https://ko.wikipedia.org/wiki/%EB%B2%94%EC%A3%BC%EB%A1%A0
수학에서 범주론(category theory)는 수학적인 구조와 그 사이의 관계를 "범주"라는 추상적 개체를 다루는 이론이다.
20세기 전반에는 수학을 이해하는 도구로 집합론을 꼽았다.
(집합론 : 수학의 이론이란 것은 모두 어떤 대상을 가지고 있는데 이 대상의 모입을 '집합'이라고 부르고 각각의 대상은 이 집합의 원소로 보는 방법)
그러나 이 대상을 이해하려면 '집합'으로 부족함을 깨달았다. '집합 사이의 관계'를 파악해야만 가능하다는 사실을 파악한다.
하여 두 집합 사이의 관계(relation)특히 함수(function)을 써서 이해한다는 집합론을 만들었다. (그것이 범주론인듯... 집합이긴 하지만 관계를 중시한다는 건가)

어떤 구조를 갖는 대상 전체의 모임(위상공간의 모임, 군의 모임, 등등)을 category라 부르고, 두 category 사이에 대응을 functor라고 부른다.
그리고 homology 이론(상동성? 어떤 형질의 진화 과정 동안 보존된 것)을 잘 보면(난 모르지만...) 대응관계(functor)만 알면 이 이론의 결과를 얻게 된다는 것을 알 수 있었다.

즉, category의 여러 성질을 알아내는데 그 성질은 functor가 다 가지고 있다는 것이다. 즉 어떤 집합을 알려 할 때, 이 집합의 요소는 몰라도! 집합에서 나오고 들어가는 함수들 전체의 합성관계만 알아도 집합의 성질을 알 수 있게 된다.
이말이다.

여기서 알 수 있는 것은 functor란 것은 이쪽 집합(세계)에서 저쪽 집합(세계)로 매핑해주는 녀석이라는 것.
https://en.wikipedia.org/wiki/Functor
- In mathematics, a functor is a map between categories.

쓰면서도 뭐가 뭔지 모르겠다. 일단 모나드로 돌아오자. 내부 함자 범주가 대체 뭐야? (찾아보니 함자가 functor의 한국말이다... 하...)
내부 함자 범주가 뭔진 잘 모르겠지만, 모나드에만 이제 집중해서 다시 찾아보자.
https://en.wikipedia.org/wiki/Monad_(category_theory)

In category theory, a branch of mathematics, a monad is an endofunctor (a functor mapping a category to itself), together with two natural transformations.

여기서는 모나드가 endofunctor라는데 괄호안에 있는 것이 뭘 말하는지는 잘 모르겠다. (functor인데 범주 자신에 매핑된다는 걸보니 아마 이런걸 말하는 가보다. f S -> S, 그러니까 이 박스에서 다른 박스 형태로 매핑되는 것이 아니라.
자기자신과 같은 박스형태로 매핑된다는 뜻인가보다... 사실 잘 모르겠다.)

함수형프로그래밍쪽 위키를 봐보자.
https://en.wikipedia.org/wiki/Monad_(functional_programming)

- In functional programming, a monad is a design pattern that defines how functions, operations, inputs, and outputs can be used together
to build generic types, with the following organization:
1. Define a data type, and how values of that data type are combined.
2. Create functions that use the data type, and compose them together into operations, following the rules defined in the first step.

모나드는 함수, 연산자, 인풋, 아웃풋이 제네릭 타입에서 어떻게 이용되는지 '아래와 같은 방식으로' 정의하는 패턴이다.
1. 데이터타입을 정의하고, 데이터타입의 값들이 어떻게 연결되는지 정의한다.
2. 첫번째 스텝에서 정의된 룰을 따라 함수들을 만든다. 그 함수들은 해당 데이터타입을 사용하고, 연산자로 그 둘을 섞는다(구성한다).
잘 모르겠지만, 수학에서의 monad랑 함수형프로그래밍의 모나드랑은 좀 다른 것 같다. 더 읽어보자.

A monad may encapsulate values of a particular data type, creating a new type associated with a specific additional computation,
typically to handle special cases of the type. For example, the simple Maybe monad encapsulates variables which may have a null value,
representing an option type, and automatically ensures that null values are not passed as arguments to functions that cannot handle them,
serving as an alternative programming technique to throwing and catching exceptions when null values arise.

모나드는 특정 값을 캡슐화 한다. (계산을 하고 박스를 생성해서 거기에 넣는다고 생각해보자.) 일반적으로 특별한 타입을 다룰 때 쓰인다고 한다.
예를들어 Maybe monad가 있다. Maybe monad는 null 값이 있을 수도 있는 값을 캡슐화 한다. 하스켈에서 Maybe 타입은 Just a | Nothing 이 두개가 있는데 Nothing이 바로 null 값을 대신한다고 생각하면 된다.
이 Maybe monad는 자동적으로 null 값을 넘기지 않는다. Just null 뭐 이렇게 넘기는 것이 아니라. Nothing이라는 값이 넘어간다. 아예 그 값(null)이 함수에 패스가 되지 않는 것이다. 그러므로 전혀 그 값을 다룰 수 없다.
그러면 일단 코딩을 할 때 그 녀석이 들어오지 않는다고 생각하고 코딩하면 된다. (null이 들어오는 것을 생각하며 코딩하면 더러워진다고 항상 코드가 더러워지지 않는가!!)
이렇게 만듬으로써 예외를 던진다거나 nullpointerException같은거 캐치하는 일은 이제 필요없게 된다.

Another example is the List monad,
where the empty list is a constant value of type List,
and the cons operator binds a plain value as the head of a previous list.

또 다른 예제는 List 모나드라고 한다.
빈 리스트는 List의 상수값이라고 한다. 그리고 cons 연산자는 값을 list의 앞(head)에 붙이는 역할을 한다.

=========================== E N D ========================
여기까지 읽고 한 번 되돌아 보자.
모나드는 그냥 프로그래밍을 할 때 쓰이는, 디자인패턴 중 하나라고 생각하는게 마음에 편할 것 같다.

자 그렇다면 이 Monad를 어떻게 쓰냐. 일단 Monad의 정보를 한번 보자.

Prelude> :info Monad
class Applicative m => Monad (m :: * -> *) where
(>>=) :: m a -> (a -> m b) -> m b
(>>) :: m a -> m b -> m b
return :: a -> m a
fail :: String -> m a

여기서 (>>=)는 bind라고 불리는 녀석인데 이 녀석이 핵심이다. (>> 이녀석은 then 이었나?) 한번 파헤쳐보자.
이 >>= 녀석이 하는 일은 한마디로 말하자면 박스에 있는 값을 함수 안에 넣는다고 생각해보자. *뇌피셜주의* (펑터에서는 박스 안에 함수를 넣었다면 이번엔 반대다! 왜냐하면 이 함수는 박스를 리턴하기 때문)
아래 타입을 보면 더 명확해진다.

(>>=) :: m a -> (a -> m b) -> m b

중간에 있는 (m -> m b)를 봐보자. 박스 안에 있는 값을 다루는데 input 값이 m a가 아니라 a 다.
이 말은 박스 안에 값만을 추출해서 함수의 아규먼트로 들어갔다는 말이다. 사용법을 봐보자.

m a >>= (a -> m b)

[]를 박스라고 해ㄷ보자.
[a] >>= a를 받아 b를 만든다 그리고 박스([])를 만들어서 거기에 b를 넣는다. -> 그러면 m b 즉, [b] 가 리턴될 것이다.
(이렇게, [a] >>= (\x -> ...) -> [b])

여기서 중요한 것은 어떤 타입(어떤 박스가 들어가 있던)이던 그 녀석들을 넣어서 계산하고 뱉어내는 것이다.

Prelude> (Just 2) >>= (\x -> return $ x + 2)
Just 4
Prelude> (Just 2.0) >>= (\x -> return $ x + 2)
Just 4.0

보면 알겠지만, 박스 안에 내용을 가져와서 x에 바인딩(그래서 >>=의 이름이 bind인가보다)되어 새로운 박스에 넣어서 리턴한다. 위에 return의 타입을 보자. a를 가져와서 m a를 뱉어낸다. 새로운 박스를 만들어서 뱉어내는 것이다.

여기까지가 오늘 정리한 내용이다.
틀린 내용이 있으면 수정을 계속 할 것이나...
무엇이 틀린 내용인지도 잘 모르는 멍청이 이기 때문에 안타깝다.

어떤 수학을 공부해야 이런 수학이론을 위키백과로 검색했을 때 나오는 내용들을 이해할 수 있을까?
함께 공부하고 아니면 함께 이걸로 무언가 만들 수 있으면 재미있을 것 같다.
남은 생도 열심히 살자.

[책리뷰] 처음배우는 블록체인을 읽고.

이 책은 블록체인에 대한 개론과 구현을 5:5로 나눠서 설명하고 있다.
처음 책의 반은 여러가지 블록체인의 방법들을 설명하고 있으며, 나머지 반은 구현을 하고 있다.
블록체인에 대해 어느정도 개론을 알고 싶고, 구현 또한 어떻게 하고 있는지 알고 싶다면 괜찮은 구성인 것같다.
필요한 용어들을 아주 간결하게 설명해준다. 구현 또한 큰 설명없이 구현을 해나간다.
위에서 설명했듯이 설명이 거창하거나 세세하지 않기 때문에 종사자가 아니라면 이해가 쉽지 않을 수 있다.
그러므로 이 책 한권으로 블록체인을 알 것이라고 생각하면 안된다. 이 책은 블록체인을 알 수 있는 길을 밝혀준다고 생각하면 된다.
세세하지는 않지만 알아야 되는 용어들이 아주 많이 담겨 있기 때문에, 그 용어들을 이용해서 질문을 하거나, 검색을 하거나 할 수 있기 때문에 괜찮은 전략이라고 생각한다.
장점이라고 생각한다.

하지만 구현을 하는 파트에서는 그 점이 단점이라고 생각한다.
어떻게 구현을 하는지 아주 간결하게 보여지면서 빠르게 넘어가기 때문에 보면서 따라하기에는 꽤나 힘들지 않을까 싶다.
하지만 그럼에도 어떻게 구현되고 어떻게 완성되가는지 지켜보는 것은 나쁘지 않은 것 같다. 정말 구현을 하고 싶으면 그것에 집중된 책을 구매하면 될 것이다.

블록체인에 대한 큰 그림을 보고 싶은 분.
블록체인에 대해 알고 있지만 정리가 필요하신 분.
위의 분들에게 추천합니다.
하지만 블록체인에 대해 상세히 알고 싶은 분이라면 위 책만으로는 부족함을 인지하시고 읽어주시면 좋겠습니다.