Common Lisp은 함수형 언어인가?

[김영태]

다음의 글은 네이버의 LISP 사용자 모임에 예전에 제가 올린 글입니다. 함수형 언어에

대한 개념 정립에 도움이 되길 바라는 마음으로 이 곳에도 올립니다.

---------------------------------------------------------------------------------------------------------------------------

많은 분들이 Common Lisp을 함수형 프로그래밍 언어로 알고 계신 것 같습니다. 이런 견해는

함수형 언어를 어떻게 정의하느냐에 따라, 맞는 견해일 수도 있고, 부적절한 표현일 일 수도

있습니다. 이번에는 제가 이해하고 있는 함수형 언어에 대해 이야기해 보겠습니다. 제 견해에

틀린 부분이나 부정확한 부분이 있다면 지적해 주시기 바랍니다.

먼저 함수형 언어를 넓은 의미에서 정의하면, Common Lisp은 함수형 언어의 조건을 다 갖추고 있습니다.

다음의 조건 4가지를 충족시키면, 그 함수는 일급 함수(fisrt-class function)라고 부르고, 일급

함수를 지원하는 언어는, '전통적인 의미'에서의 함수형 언어라고 부를 수 있습니다.

1) 함수 객체를 동적으로 생성할 수 있다.

2) 함수 객체를 변수에 대입할 수 있다.

3) 함수 객체를 함수의 인수로 전달할 수 있다.

4) 함수 객체를 함수의 반환값으로 반환할 수 있다.

특히 위의 세 번째와 네 번째 조건을 충족시키는 함수를 고차 함수(higher-order function)라고

부릅니다.

Common Lisp은 아마도 위의 네가지 조건 모두를 만족시키는 최초의 언어일 것입니댜.

그런데 문제는 요즘 새로 등장하는 언어들 거의 대부분이 위의 네 조건을 모두 충족시키고 있다는

것입니다(리습을 흉내내고 있다고 봐도 무방합니다). JavaScript마저도 위의 네 조건을 모두 충족시키고 

있는데, 그렇다면 JavaScript도 함수형 언어라고 불러야 합니다.

더 심각한 문제는, Common Lisp을 함수형 언어로 인정한다 할지라도, Common Lisp이라는 언어를

과연 함수형 언어라는 하나의 카테고리로 규정할 수 있는가 하는 것입니다. 저의 견해는

No입니다. CLOS를 내장한 이후부터는 Common Lisp은 이미 객제지향 언어입니다. 또한 진정한

'메타 프로그래밍 언어'(즉, 매크로 언어)라고도 규정할 수도 있습니다. Common Lisp이라는 언어

자체는 계속 진화해 왔고, 앞으로도 그럴 것입니다. 따라서 Common Lisp을 함수형 언어라는

하나의 카테고리에만 담을 수는 없습니다.

하지만 Common Lisp에는 위에서 제가 말한 것처럼, 분명 함수형 언어로서 갖추어야할 요소들을,

충분하지는 않지만, 어느 정도 갖추고 있는 것은 분명합니다.

그러면 지금부터는 요즘 각광받기 시작하고 있는 '엄격한' 의미에서의 함수형 언어에 대해 말해

보겠습니다.  객체지향 프로그래밍이 갖는 문제점을 극복하고자 하는 대안으로서 요즘 주목받고

있는 '함수형 언어'는 위의 4가지 조건에 더해서, immutable 자료형을 기본(default)으로

제공해야 합니다. 이 조건을 하나 더 충족시켜야, 요즘에 말하는, 진정한 의미의 함수형 언어라고

말할 수 있습니다. immutable 자료형을 기본으로 하면, 메모리 소요량도 많아지고 처리 시간도

길어지는데, 왜 굳이 immutable 자료형을 기본으로 할까요? 그것은 immutable 자료형을 기반으로

연산을 수행하면, 프로그램의 복잡도가 엄청나게 줄어들 수 있기 때문입니다.

과거에 절차지향 프로그래밍의 문제점을 극복할 수 있는 대안으로 객체지향 프로그래밍이

등장한 이유가 무엇이었나요? 전역 변수의 사용을 줄이고, 변수를 클래스 안에 가두어 놓은 후에, 

클래스 내의 멤버변수만 접근 가능하도록 '강제'한 이유가 무엇입니까? 그 이유는 전역 변수의 경우에는

프로그래밍 내의 어떤 함수에서도 접근이 가능해서, 그에 따라 어떤 함수가 그 변수를 건드렸는지

추적하기 무지무지 어렵기 때문이지 않았습니까? 물론 전역 변수를 많이 사용해서 프로그래밍한다

해도, 프로그래머가 아주 아주 조심스럽고 세심하게 프로그래밍하면 그 프로그램은 잘 돌아갈 수

있겠죠. 하지만 그렇게 세심하고 꼼꼼한 프로그래머도, 자신이 짠 프로그래밍 소스 코드를 2개월

정도 지나 들여다 봐도 자신이 짠 코드를 잘 이해하지 못하는데, 하물며 다른 사람이 짠 코드를

유지/보수해야 하는 입장에서는, 전역 변수의 남발이 악의 화신으로 느껴질 겁니다. 그래서

사람들이 객체지향 프로그래밍으로 많이 돌아섰지요. 그런데 여기서 한가지 중요한 원리가 발견됩니다.

그것은 변수의 값을 변경할 수 있는 함수들의 범위를 줄였다는데 있습니다. 그렇다면 상태를 유지하는 

변수가 아예 없다면 어떻게 될까요? 바로 이것이 요즘에 등장한 함수형 언어들이 추구하는 목표입니다. 

그런데 객체 지향 프로그래밍도, 설계하고자 하는 클래스의 크기가 커지거나, 다른 클래스에

의존하는 내부 변수들의 수가 증가할수록, 그리고 상속 관계가 복잡해질수록, 클래스 내부 변수를

건드리는 멤버 함수들의 수가 더불어 증가하기 마련입니다. 그래서 그 클래스 내부의 변수들을,

어떤 멤버 함수 내에서 건드리는 지 추적하는 일도 만만치 않은 일이 되어 버립니다. 전역 변수

관리할 때와 비슷한 현상이 나타나기 시작한다는 것이지요. 

여기서 함수형 언어에서의 immutable 자료형의 진가가 드러나게 됩니다. 함수형 언어에서는

상태(state)를 저장하는 변수의 사용을 없애는 것을 목표로 함니다. 하지만, 상태를 저장하는 변수를 

전혀 안쓸 수는 없습니다. 그래서 변수의 상태값을 변경하는 겻을 오히려 예외적인 상황으로 간주합니다.

그렇게 되면 디버깅할 때 디버깅의 단위가 함수 하나로 국한됩니다. 객체 지향

프로그래밍에서처럼, 클래스 내의 다른 멤버 함수가 클래스의 내부 변수를 언제 어떻게 건드리는지

전혀 신경쓸 필요가 없어집니다.

따라서 '프로그램의 복잡도를 줄여준다'는 의미로, 그리고 그것을 실현하기 위해 immutable

자료형을 기본으로 제공해야 한다는 의미로 함수형 언어를 정의한다면, Common Lisp은 함수형

언어가 아닙니다.

[박상규]

이와 관련된 논의가 있네요.

http://stackoverflow.com/questions/3962604/is-javascript-a-functional-programming-language

위 링크에서 재밌는 것은 데이타 불변성만을 놓고 보게 되면 

스칼라로 함수형 언어가 아니라는 얘기가 된다는...

또 얼랭도 무사하지 못하게 된다는...

여기서는 함수형 언어에 대한 합의된 정의는 없다는 것하고

하지만 명령의 나열이나 객체간 통신이 아니라 함수의 평가에 의한 프로그래밍이 주 프로그래밍 방식인 언어를 함수형이라고 하는 것이 아닌가 하는 점에 동의하고 싶네요.

사실 자바스크립트가 함수의 평가에 의한 프로그래밍을 주요한 프로그래밍 방식으로 제공하지 않는다는데에는 다들 동의하실 거라 생각합니다.

Common Lisp의 경우 위키피디아에서는 멀티 패러다임 언어로 나와 있습니다.

또한 위키피디아의 Functional Language 페이지에는 prominent functional programming languages로 가장 먼서 Common Lisp이 나오고 있네요. Clojure와 함께...

데이타 불변성이 분명 매우 중요한 역할을 한다는데 동의합니다만...

그것으로 함수형 언어인가 아닌가를 가르는 주요 기준이 될 수 있는가에는 좀...

결국 그 언어가 주로 제공하는 프로그래밍 스타일이 어떤 프로그래밍 스타일을 제공하느냐의 문제가 보다 중요한 것이 아닐까 합니다.

2013년 8월 27일 오후 2:07, 김영태 <phil...@gmail.com>님의 말:

--
Google 그룹스 'Lisp을 좋아하는 사람들의 그룹(한국 리스퍼)' 그룹에 가입했으므로 본 메일이 전송되었습니다.
이 그룹에서 탈퇴하고 더 이상 이메일을 받지 않으려면 lisp-korea+...@googlegroups.com에 이메일을 보내세요.
이 그룹에 게시하려면 lisp-...@googlegroups.com(으)로 이메일을 보내세요.
http://groups.google.com/group/lisp-korea에서 그룹을 방문하세요.
더 많은 옵션을 보려면 https://groups.google.com/groups/opt_out을(를) 방문하세요.

[blueiur]

상태 변수를 없애는게 목적이 아니라 명시적으로 격리시는게 목적 아니였나요? 

개인적으로 first class function보다 Immutable 자료형의 유무가 함수형 언어에 있어 더 큰 영향을 미친다고 생각합니다.

또한 immutable 자료형 사용에 장점은 상태를 변경하지 않으면서 속도를 유지하기 위해서도 있을거라 생각합니다. 

[김영태]

그 말이 그 말인 것 같습니다만, 상태를 유지하는 변수를 최소화하는 데 있다고 보면 될 듯 합니다.

명시적 격리라는 표현도 좋은 표현인 것 같습니다만, 명시적으로 격리만 하면, 상태 변수가 많이 

있어도 무방하다는 의미로도 해석될 소지가 있는 듯 해서요.

 

2013년 8월 27일 화요일 오후 11시 6분 43초 UTC+9, daewon jeong 님의 말:

[박상규]

[ANSI Common Lisp] by Paul Graham. p.22 에서는 함수형 프로그래밍에 대해 다음과 같이 정의했네요.

"Functional programming means writing programs that work by returning 

values, instead of by modifying things. It is the dominant paradigm in Lisp. 

Most built-in Lisp functions are meant to be called for the values they return, 

not for side-effects."

즉 함수형 프로그래밍이란 부수효과없이 값을 리턴하는 함수로 프로그래밍하는 것을 말하는 것인데, 이것이 Lisp의 지배적 패러다임이고 대부분의 Lisp 내장 함수들이 이러한 특성을 갖는 다는 것인데요.

이를 두고 미루어 볼 때 폴 그레함은 리스프를 함수형 언어로 본 것 같구요.

비록 리스프에서 데이타가 불변이 아니더라고 부수효과가 없는 함수를 통한 프로그래밍이 주요한 패러다임이라면 리습을 함수형 언어로 볼 수 있다는 것으로 보입니다.

즉 언어에서 제공하는 데이타가 불변이냐 아니냐 보다는 부수효과 없는 함수를 평가하는 방식으로 프로그래밍을 하는 것이 주요한 패러다임이라면 함수형 언어라고 보는 것이 맞지 싶네요.

또한 [Land of LISP] 14장에서 정의하고 있는 함수형 프로그래밍은 

"모든 코드를 작성할 때 함수를 사용하는 프로그래밍 스타일"

이라 정의하고, 이 때 함수는 수학 함수와 같다는 것인데, 다음과 같이

* 함수는 같은 인자가 주어지는 한 항상 같은 결과를 반환한다.(참조투명성)

* 함수는 상수로 지정한 것이 아니라면 함수 밖에서 정의된 변수를 참조하지 않는다.

* 함수는 어떤 변수도 수정하지 않는다.

* 함수의 목적은 오로지 결과를 반환하는 것 뿐이다.

* 함수는 팝업 윈도를 띄우거나 Bing 싸이트에 접속하는 등, 외부에 노출되는 어떠한 일도 수행하지 않는다.

* 함수는 키보드나 하드디스크 같은 외부 자원에서 정보를 읽어오지 않는다.

정의하면서

"가능한 한 이러한 규칙을 지켜서 코딩한다면 그 코드는 함수형 스타일로 작성되었다고 말 할 수 있다." 라고 합니다.

함수형 스타일 프로그래밍은 은 C/C++/Java 언어로도 가능합니다. 다만 그것이 주요한 프로그래밍 스타일은 전혀 아닌 것이라서 함수형 언어가 할 수가 없는 것이죠.

결국 함수형 스타일의 프로그래밍이 주요한 프로그래밍 스타일이라면 그 언어를 함수형 언어라고 할 수 있다는 것이지 싶구요.

반면 [Clojure Programming] 2장에서는 클로져에서의 함수형 프로그래밍을 다음과 같이 정의한다고 합니다.

• A preference for working with immutable values; this includes:

— The use of immutable data structures that satisfy simple abstractions, rather

than mutable bags of state

— The treatment of functions as values themselves, enabling higher-order

functions

• A preference for declarative processing of data over imperative control structures

and iteration

• The natural incremental composition of functions, higher-order functions, and

immutable data structures in order to solve complex problems by working with

higher-level (or, right-level) abstractions

Chas Emerick의 경우 Immutability를 강조하고 있구요.

하지만 또 반면 [Joy of Clojure]에서는 상황이 좀 다르구요.

즉 함수형 프로그래밍을 설명하는 7장에서는 Immutability에 대한 얘기 거의 없구요. 6장의 On Immmutability에서 Immmutability의 장점을 소개하면서 결국 멀티 스레딩에서의 강점을 얘기하고 있구요.

결국 클로져에서의 Immmutability의 채택은 함수형 프로그래밍의 측면보다는 멀티스레딩에 대처하기 위해서 채택된 것으로 보이는 것 같습니다.

사실 Immmutability 이 보장되야 클로져의 강점인 STM도 가능해 지는 거구요. ^^;

2013년 8월 28일 오전 12:10, 김영태 <phil...@gmail.com>님의 말:

--

[jinisrolling]

언어는 모르겠지만 Common lisp 프로그래머들은 대체로 함수형 프로그래머는 아닌 것 같습니다.