몇년전 코드 리뷰 날, 선배 개발자 한분이 새로운 것을 보여주셨었습니다.

Objective-C의 코드를 두 개 이상의 파일로 나누는 것이었는데요. 

지금은 Swift로만 개발해서 활용하고 있지 않지만, 기록 차원에서 글로 작성해보았습니다.

 샘플로 만든 프로젝트의 'Project Navigator'는 아래와 같습니다.

 특이하게도 ViewController+DiviedFile.m이라는 파일이 있는데요, ViewController.m에 

넣으려던 코드를 별도의 파일로 분리한 것입니다. 

어떤식으로 분리한 것인지 보기 위해 ViewController.m의 코드를 살펴보면 아래와 같습니다.

 FILE_DIVIDE_FLAG라는 상수가 선언되어 있고, 

마치 헤더 파일을 추가한 것처럼 ViewController+DiviedFile.m을 추가했습니다.

 ViewController+DiviedFile.m의 코드도 볼께요.

 매크로를 사용해서, 상수 존재 여부에 따라 @implementation과 @end를 해당위치에 삽입하는 코드가 있습니다. @implementation과 @end가 있어야 ViewController+DiviedFile.m을 정상적인 형태를 갖춘 코드로 인식하고, 컴파일이 될때는 @implementation과 @end가 없어야해서 지시자(Directive)를 저런 형태로 작성한 것입니다.

 여기까지 작업하고 빌드를 하면, 심볼이 중복된다는 에러를 볼 수 있습니다. 해결하려면 ViewController+DiviedFile.m를 컴파일 대상이 되지 않게 하면 됩니다(전처리 단계에서 ViewController.m에서 ViewController+DiviedFile.m의 내용을 해당 위치에 추가하기 

때문에 괜찮습니다.).

 Xcode에서는 Target -> Build Phases -> Compile Sources에서

ViewController+DiviedFile.m를 지워주면 됩니다.

1. Evaluation이란?

: 수학에서, 올바른 답을 얻기 위해 식(Expression)을 평가하는 방법은 중요한 이슈이다. λ Calculus에서도 마찬가지다.

2. 원칙과 전략

2-1. Evaluation Principle

: 식을 평가하기 위한 2가지 기본적인 원칙이 있는데, 각각 Eager Evaluation과 Lazy Evaluation이다.

Eager Evaluation

: 언제나 인자를 Evaluation하고, 함수를 인스턴스화(Instantiate) 한다.

Lazy Evaluation

: 인자가 필요한 시점에 Evaluation한다.

2-2. Evaluation Strategy

: 위의 기본적인 원칙에서 2개의 주요한 평가 전략(Evaluation Strategy)이 탄생하는데, 각각 Normal Order와 Applicative Order이다.

Normal Order(call by name으로도 알려져 있음)

: 언제나 맨 왼쪽의 것들부터 줄여나간다. 그리고 파라메터는 함수로 전달되기 전까지 평가하지 않는다.

Applicative Order(strict evaluation 또는 call by value로도 알려져 있음)

: 전달되었거나 대체된 파라메터를 먼저 평가한다.

 아래의 예제는, 각 Evaluation Strategy를 이해하는데에 도움이 될 것이다.

Example) 다음 식을 Normal Order, Applicative Order를 이용해서 평가(Evaluation)해보자.

(λ a.λ b.a)c((λ d.e)d)

Normal Order

: (λ a.λ b.a)c((λ d.e)d)  ->β  (λ b.a)[a＼c]c((λ d.e)d)  =  λ b.c((λ d.e)d)

->β  (c)[b＼((λ d.e)d)]  =  c

Applicative Order

: (λ a.λ b.a)c((λ d.e)d)  ->β  (λ a.λ b.a)c(e[d＼d])  =  (λ a.λ b.a)c(e)

->β  (λ b.a)[a＼c](e)  =  (λ b.c)(e)  ->β  c[b＼e]  =  c

※ 어떤 평가 전략을 쓰더라도 결과는 항상 같을까? 그렇지 않다. 위의 예와 같이, 다음 식을 평가해보자.

(λ x.a)((λ x.x x)(λ y.y y))

Normal Order

: (λ x.a)((λ x.x x)(λ y.y y))  ->β  a[x＼((λ x.x x)(λ y.y y))]  =  a

Applicative Order

: (λ x.a)((λ x.x x)(λ y.y y))  ->β  (λ x.a)(x x)[x＼(λ y. yy)]  =  (λ x.a)((λ y. yy)(λ y. yy))

->β  (λ x.a)(yy)[y＼(λ y. yy)]  =  (λ x.a)((λ y. yy)(λ y. yy)) - 무한 반복된다.

 각 평가 전략을 도입한 결과가 다르다. 따라서 어떤 평가 전략을 사용하느냐는 꽤 중요하다고 볼 수 있다. Church-Rosser 이론에 의하면, 식을 평가할 때 무한 반복되지 않고 끝날 수 있다면 Normal Order를 해당 식에 적용해도 끝날 수 있다. 그리고 똑같은 식에 두 평가 전략을 적용했을 때 모두 끝날 수 있다면, Alpha-conversion전까지 동일한 결과가 나온다.

3. Referrence

- λ Calculus tutorial

1. Reduction이란?

: λ Calculus에서 식을 줄여서 간단한 형태로 만드는 것. 식을 변형시키는 것.

2. Beta, Alpha Eta Reduction

2-1. Beta Reduction

: 아마, 가장 직관적이지 않을까 싶다. β reduction이란,  함수를 적용한 결과를 계산하는 절차를 말한다. 본질적으로, 직접 대체하는데 다음 식을 보자.

((λ (x).BODY) a)   ->β   BODY[a\x] = BODY                            ※  ->β는 β reduction을 의미한다.

식이 변하는 과정을 단계별로 보면, 

1)  ((λ (x).BODY) a)

: x는 받은 인자이며, BODY에 넘겨진다. 지금 상황은 이 함수에 a를 넘기려는 상황이다.

2) ->β   BODY[a\x] = BODY

: BODY[a\x]는, 'BODY에 있는 모든 x를 a로 대체한다'는 의미다. BODY에 x가 없다면,

아무 변화가 없으므로 그냥 BODY가 된다.

β reduction으로 식을 줄이는 예제들

1) (λ z.f z)b  ->β  (f z)[b\z] = (f b)

2) (λ z.y)c  ->β  y[c\z] = y 

3) (λ y.c)((λ z.f z) b)  ->β  (λ y.c)((f z)[b\z])

= (λ y.c)(f b)

->β  c[(f b)\y]

= c 

2-2. Alpha Reduction

: 식을 많이 줄이진 못한다. Renaming이라고 부르기도 한다. Alpha Reduction을 할때, 주의할 점이 있는데 변수의 Scope를 바꾸면 안된다는 것이다. 다음 식을 보자.

(λ (x) (+ x y))

 위의 식에서, x는 함수의 부분으로 쓰이고 있다. 이걸 'x는 Lambda식의 Scope에 Bound되었다'라고 표현하며 'y는 free'라고 표현한다. (λ (x) (+ x y))를 다음과 같이 적을수도 있다.

(λ (x) (+ x y))  ->α  (λ (z) (+ z y))

Alpha Reduction 전후는 동일하다. 그냥 변수의 이름을 바꿨을 뿐이다. Alpha Reduction을 적용할때... 변수의 Scope를 바꾸지 않도록 주의해야 하는데, 다음 식을 보자.

(λ (x) (+ x y))  ->α  (λ (y) (+ y y))

 y는 처음에 Unbound였으므로, Alpha Reduction후에 y의 의미가 바뀌었다. 이걸 Name Conflict라고 부른다. Alpha Reduction전에는 y의 Scope가 Global이었으나 Alpha Reduction후에 Local로 바뀌었다.

2-3. Eta Reduction

: Abstractions에서 쓸모없는 변수들을 제거하기 위해 쓴다. 다음 식을 보자.

((λ (x).BODY) x)  ->η  BODY

 위의 Function Abstraction에서, 함수가 쓰일때마다 인자는 그저 BODY에 전달될 뿐이다. 따라서 BODY와 동일하다. 이전의 Alpha Reduction과 비슷하게, Eta Reduction도 Name Conflict가 없어야 한다. 그래서 x는 BODY에서 free이면 Eta Reduction을 적용하면 안된다. Name Conflict를 피하기 위해, 먼저 Alpha Reduction을 하는 것도 좋다.

3. Reference

- λ Calculus tutorial

- haskell wiki