/ Etc...?!

A History of Haskell - Being Lazy With Class(Part.1)

저자

1. Introduction

1990년 4월 1일에 발간된 Haskell 보고서의 첫버전(Haskell Report, Version 1.0)의 머릿말엔 Haskell의 시작을 유추할 수 있는 인용구를 소개하고 있습니다.

  • 1987년 오레곤 주 포틀랜드에서 열린 Functional Programming Languages and Computer Architecture의 회의 내용은 1) 공통된 형태의 functional programming languages를 설계, 언어에 관한 아이디어를 손쉽게 전달, 응용 프로그램 개발을 위한 안정적인 기반을 제공하고 다른 사람들이 functional programming languages를 사용하도록 장려하는 방법을 논의하는 위원회가 구성되어야 한다고 결정
  • 표현력과 의미론이 비슷하고 non-strict, purely functional을 기반으로 한 프로그래밍 언어가 과도하게 만들어지고 있기 때문에 언어의 일관적인 형태가 없어서 널리 사용되지 못하고 있음

위의 인용구에서 거론한 문제를 해결하고, 엄격하고 순수한 함수형 형태의 공통 언어를 충족시키기 위한 대안으로 Haskell이 제안되었고, 이 모든 설계 과정을 주도할 위원회를 구성하게 되었습니다.

논문의 구성

  • 1부의 내용(기원과 원리)

    • Haskell의 기원(Section 2)에 대해 설명합니다.
    • Haskell의 원리와 발전과정(Section 3)을 설명합니다.
  • 2부의 내용(언어의 발전)

    • 문법(Section 4)을 설명합니다.
    • 데이터 타입(Section 5)을 설명합니다.
    • 타입 시스템(Section 6)을 설명합니다.
    • 모나드와 입/출력(Section 7)을 설명합니다.
    • 외부 인터페이스(Section 8)를 설명합니다.
  • 3부(구현과 도구)

    • GHC, hbc, hugs, nhc, Yale Haskell(Section 9)에 대해서 소개합니다.
    • 프로파일 링 및 디버깅 도구 (Section 10)를 설명합니다.
  • 4부(응용 프로그램과 영향력)

    • 응용 프로그램에서 사용된 고유한 특징(Section 11)을 설명합니다.
    • 다양한 사용자 커뮤니티에 미치는 영향(Section 12)을 설명합니다.

본 논문의 목표는 누가 참여했는지, 그리고 어떤 것이 구성원들에게 영감을 주었는지를 포함한 역사를 전달하는 것으로 이 논문은 기술적인 설명이나 튜토리얼이 아닌 발전 과정에 집중합니다. 저자들은 Haskell의 발전 과정을 설명하려고 노력했고 구성원들의 일화와 개인적 반성을 포함시킴으로써 열정적이고 생상한 모습을 담고자 하였으나 설명이 왜곡될 수 있고, 모든 것을 담을 수 없다는 단점을 가집니다.

Part 1

2. The genesis of Haskell

  • 1978년 John Backus(Fortran, BNF)는 <<Can Programming Be Liberated from the von Neumann Style? A Functional Style and Its Algebra of Programs>>를 통해 수학적인 논의가 아닌 실제로 사용할 수 있는 새로운 형태의 함수형 프로그래밍 방법을 제안하였습니다.

  • 1950년대 후반 John McCarthyLisp를 만들었고, 1960년대 Peter LandinChristopher Strachey는 프로그래밍 언어를 모델링하는데 람다 미적분학(the lambda calculus)이 중요하다는 사실을 확인하고 추상 기계(abstract machines)와 denotational semantics을 통해 operational semantics의 기초를 만들었습니다.

  • 몇 년 후 StracheyDana Scott은 도메인 이론은 denotational semantics에 수학적인 의미를 부여했습니다. 70년대 초, Rod BurstallJohn Darlington패턴 매칭에 의한 함수 정의를 사용하여 first-order functional language로 변환할 수 있는 방법을 만들었습니다. 같은 시기에 Strachey의 제자인 David Turner는 Landin의 ISWIM a.k.a ISWYM의 하위 집합에서 유래 된 a sugared lambda calculus를 사용해서 어휘적으로 범위가 정해져(lexically scoped variables) 있고, 패턴 매칭에 관한 BurstallDarlington의 아이디어가 포함된 실행 가능한 a pure higher-order functional languageSASL을 개발했습니다.

  • 70 년대 후반, Gerry SussmanGuy SteeleLisp의 파생언어 중 하나인 Scheme을 개발했습니다. Scheme은 lexical scoping를 구현했고, lambda calculus와 밀접하게 관련되어 있습니다. Robin Milner는 거의 같은시기에 MLEdinburgh의 LCF 정리를 증명하기 위한 메타언어로 개발하였습니다. ML에 대한 Milner의 다형성(polymorphic type system)은 많은 영향력을 끼쳤습니다. SchemeML은 모두 엄격한(call-by-value) 언어였고 명령형 기능(features)을 포함하고 있었지만 함수형 프로그래밍 스타일을 촉진하고 특히 고차 함수(higher-order function)을 많이 사용했습니다.

2.1 The call of laziness

그런데 70년대 후반과 80년대 초반에 뭔가 새로운 일이 일어났습니다. 일련의 출판물(series of seminal publications)에서 중요한 프로그램을 작성하기 위한 수단으로서 lazy(non-strict, call-by-need) functional languages에 대한 관심의 촉발 시켰습니다. Lazy evaluation은 독립적으로 세 번의 제안이 있었던 것으로 보입니다.

  • Dan FriedmanDavid WiseLisp의 관점에서 "Cons should not evaluate its arguments(단점은 그 주장을 평가해서는 안됩니다.)"(Friedman and Wise, 1976)라고 평가하였습니다.
  • Peter Henderson(Newcastle)과 James H. Morris Jr.(Xerox PARC)는 "A lazy evaluator"(Henderson and Morris, 1976)를 발표했습니다. 그들의 아이디어의 기반을 제공했던 Vuillemin(Vuillemin, 1974)과 Wadsworth(Wadsworth, 1971)를 인용하지만 POPL에서 그 아이디어를 대중화하였다. Lisp의 변종을 사용하여 denotational semantics과 evaluator의 관계를 보여주었다.
  • David Turner(St. Andrews와 Kent)는 영향력 있는 일련의 언어를 소개했습니다. 1972년에 stric한 언어로 개발되었지만, 1976년에 lazy한 SASL(St Andrews Static Language)(Turner, 1976)를 1982년에 KRC(Kent Re-cursive Calculator)(Turner, 1982)를 소개하였습니다. Turner는 lazy evaluation을 사용한 프로그래밍 방법과 다양한 종류의 행동양식을 사용하기 위한 lazy lists를 소개하였습니다. SASLBurroughs에서 운영체제를 개발하는데 사용되었습니다. 순수하고(pure), 게으른(lazy), 함수형 프로그래밍(functional programming)의 대대적인(in the large) 첫 번째 사례가 거의(almost) 확실합니다.

동시에 lazy languages를 구현하는 새로운 방법에 대한 노력이 있었습니다.

  • 소프트웨어에서 그래프 축소(graph reduction)를 기반으로 한 다양한 기법이 탐구되었으며 특히 TurnerSK combinators를 아주 우아하게(inspirationally elegant) 사용했습니다.(Turner의 작업은 Alonzo Church의 lambda calculus(Church, 1941)의 변형방법인 Haskell 커리인 combinatory calculus(Curry and Feys, 1958)의 기초가 되었습니다.)
  • 이 모든 것이 근본적으로 다른 'non-von Neumann' 하드웨어 아키텍처로 이어질 수 있다는 점입니다. 다양한 종류의 데이터 흐름 및 그래프 축소 기계를 구축하기위한 몇 가지 중요한 프로젝트가 진행 중 (또는 진행 되고) 이었습니다(MITId 프로젝트(Arvind and Nikhil, 1987), UtahRediflow 프로젝트(Keller et al., 1979), Cambridgethe SK combinator 기계인 SKIM(Stoye 외, 1984), the Manchester dataflow 장치(Watson and Gurd, 1982), ImperialALICE paraller reduction 장치(Darlington and Reeve, 1981), Burroughs NORMA combinator 장치(Scheevel, 1986) 및 UtahDDM dataflow 시스템(Davis, 1977)). 이 아키텍처 지향적인 작업의 상당 부분은(전부는 아니지만)은 별다른 소득이 없었다고 판명되었는데, 나중에 상투적인(stock) 아키텍처 컴파일러가 특수용도(specialised) 아키텍처를 능가 할 수 있다는 것을 알게되었습니다. 그러나 그 당시에는 모두 급진적이고 흥미로웠습니다.

80년대 초반 몇몇 주요 회의가 해당 분야에 추가적인 자극을 주었습니다.

  • 1980년 8월, 캘리포니아 주 스탠포드에서 열린 첫 번째 Lisp 회의에서 Burstall, Dave MacQueenDon Sannella on Hope가 대수 데이터 유형(algebraic data types)을 도입한 언어를 소개하였습니다(Burstall 등, 1980).
  • 1981년 7월 Peter Henderson, John Darlington, David TurnerFunctional Programming and its Application 관한 고급 과정을 Newcastle에서 이수했습니다(Darlington et al., 1982). 참석자들 중에는 Gerry Sussman, Gary Lindstrom, David Park, Manfred Broy, Joe StoyEdsger Dijkstra가 참석했습니다(Hughes and Peyton Jones는 학생으로 참석했습니다). Dijkstra는 해당 주제에 대한 논의에 별다른 인상을 받지 못했지만 다른 많은 참석자들에게는 하나의 분수령이 되었습니다.
  • 1981년 9월, Functional Programming Languages and Computer Architecture(FPCA)에 관한 첫번째 회의가 뉴 햄프셔 포츠머스에서 개최되었습니. 여기 Turner는 <>를 발표하였습니다(Wadler는 그의 첫번째 컨퍼런스 발표도 하였습니다). FPCA는 2년에 한번씩 개최되는 주요 컨퍼런스로 자리 잡았습니다.
  • 1982년 9월, 현재 LFP라고 이름 붙여진 두번째 Lisp 컨퍼런스가 펜실베이니아 주 피츠버그에서 열렸습니다. Peter Henderson(헨더슨, 1982)이 functional geometry(Henderson, 1982)에 대해 발표했고 Turner는 infinite data structures를 가진 프로그래밍에 관한 초청 강연을 했습니다(Hudak, Hughes,와 Peyton Jones의 첫번째 논문도 공개되었습니다). 이 회의에 특별 게스트로 ChurchCurry(아마도 뉴욕의 마술사인 Paul Curry일 것으로 추정)가 포함되었습니다. 저녁 식사 후 Barkley Rosser에 의해 간단한 대화가 이어졌고, Curry's paradox의 증명을 발표했을 때 그것을 Y combinator와 관련짓고 Church-Rosser 정리의 새로운 증명을 선보였습니다. LFP는 2년에 한번씩 열리는 중요한 컨퍼런스가 되었습니다. (1996년에 FPCA는 LFP와 결합하여 ICFP(Functional Programming on International Functional Programming)라는 학회가 되었으며 이 분야의 주요 컨퍼런스로 현재까지 남아있습니다)
  • 1987년 8월, 텍사스 대학의 Ham RichardsDavid Turner는 UT의 "Year of Programming"의 일환으로 텍사스 오스틴에서 선언적 프로그래밍(Declarative Programming)에 관한 international school을 조직했습니다. 연사로는 Samson Abramsky, John Backus, Richard Bird, Peter Buneman, Robert Cartwright, Simon Thompson, David TurnerHughes가 있었습니다. 학교의 주요 부분은 Miranda를 사용하는 실용적인 수업과 함께 lazy functional programming 과정이었습니다.

이 모든 것에 엄청난 관심을 보였습니다. functional programming의 단순성과 우아함은 당시의 저자와 다른 연구자들을 사로 잡았습니다. Lazy evaluation(순수한 call-by-name lambda calculus, 무한 데이터 구조를 표현하고 조작 할 수있는 놀라운 가능성, 그리고 간단하고 아름다운 구현 기술)은 마약같은 매력이 있었다.

2.2 A tower of Babel

이 모든 활동의 결과로 1980년대 중반까지 순수한 lazy languages에 대한 설계 및 구현 기술에 관심이 있는 수 많은 연구자가 있었습니다. 사실, 우리 중 많은 사람들이 lazy languages를 독자적으로 설계했고 바쁘게 만들었습니다. 우리의 구현 기술을 설명하기 전에 먼저 언어를 설명하는 논문을 쓰고 있었습니다. 이 lazy Tower of Babel에는 다음과 같은 언어가 포함됩니다.

  • Miranda, SASLKRC 후계자인 MirandaDavid Turner가 SK combinator reduction를 사용하여 설계하고 구현했습니다. SASLKRC는 타입이 지정되지 않았지만 Miranda는 다형성 및 타입 추론을 추가했습니다. 이 아이디어는 ML에서 매우 성공적으로 입증되었습니다.
  • Lazy ML(LML)은 AugustssonJohnsson에 의해 Chalmers에서 개척되었으며 Peyton Jones가 University College London에서 채택했습니다. 이 노력으로 G-machine라는 영향력을 가진 것을 개발하게 되었고, lazy functional programs을 다소 효율적인 코드로 컴파일 할 수 있다는 것을 보여주었습니다(Johnsson, 1984; Augustsson, 1984)
  • OwwellWadler가 개발 한 lazy language로, KRCMiranda의 영향을 받았고 Owwell의 차기 변형 버전 인 OL도 영향을 받았다. BirdWadlerMirandaOrwell에 수학 표기법에 가까운 문법을 사용하여 "바벨탑"을 피한 기능적 프로그래밍에 대한 영향력있는 책을 공동 저술했다(Bird and Wadler, 1988).
  • Alfl, HudakSchem과와 T(Scheme의 변형)를 위해 개발된 기술을 기반으로 컴파일러뿐만 아니라 Alfl을위한 a combinator-based interpreter를 개발했습니다(Hudak, 1984b; Hudak, 1984a).
  • Id, ArvindNikhilMIT에서 개발 한 엄격하지 않은 데이터 흐름 언어로, 목표는 dataflow machine 이었습니다.
  • Clean, Rinus Plasmeijer와 그의 동료(Brus 등, 1987)가 Nijmegen에서 개발한 graph reduction에 기반한 lazy language based explicitly 언어입니다.
  • Ponder, Jon Fairbairn이 고안한 언어인 Impromative higher-rank type systemlexically scoped type 변수가 SKIM의 운영 체제를 작성하는데 사용되었습니다(Fairbairn, 1985; Fairbairn, 1982).
  • Daisy, Cordelia Hall, John O'Donnell 및 그들의 동료(Hall and O'Donnell, 1985)가 인디애나에서 개발 한 변형된 lazy Lisp를 개발하였습니다.

Miranda를 제외하고는 모두 기본적으로 하나의 목표를 위해서 개발된 언어였으며 디자인, 구현 및 사용자 측면에서 부족함을 보였습니다. 각각 흥미로운 아이디어가 많았지만 한 언어가 다른 언어보다 월등히 뛰어나다고 주장할 수 있는 근거는 거의 없습니다. 그와 반대로, 우리는 그것들이 대략적으로 비슷한 구문을 사용하지 못한다고 느꼈습니다. 왜 우리는 우리 모두가 혜택을 누릴 수있는 공통의 공통 언어가 하나도 없었는지 궁금해하기 시작했습니다.

2.3 The birth of Haskell

1987년까지는 필요한 모든 것을 하나의 것으로 뭉칠 수 있도록 촉진시키는 다양한 이벤트들이라 할 수 있습니다. 이 사건은 Peyton Jones가 1987년 Oregon 포틀랜드의 Functional Programming and Computer Architecture Conference (FPCA)에서 Hudak을 만나기 위해 Yale에 머물렀던 87년 가을에 일어났습니다. 상황을 논의한 후 Peyton JonesHudak은 FPCA에서 회의를 시작하여 새롭고 공통된 기능 언어를 디자인하는데 관심을 가지기로 결정했습니다. Wadler는 또한 FPCA로가는 도중에 Yale에서 멈추었으며 회의에 대한 아이디어를 지지했습니다.

FPCA 회의는 Haskell 설계의 시작을 알렸지만 우리는 언어에 대한 이름이 없었으며 기술 토론이나 설계에 관한 결정을 하지 않았습니다. 회의의 핵심 포인트는 앞으로 나아갈 수있는 가장 쉬운 방법중 하나로 기존 언어를 사용하여 발전시키는 것 이었습니다. 개발중인 모든 lazy language 중 David TurnerMiranda가 가장 좋은 후보였습니다. pure하고 잘 설계되어 있으며 Turner의 회사 인 Research Software Ltd의 제품으로 관리되었으며 120개 사이트에서 운영되었습니다. Turner는 회의에 참석하지 않았으므로 위원회의 첫 번째 조치 항목은 Miranda를 새로운 언어의 출발점으로 채택 할 수 있는지 Turner에게 요청하는 것이라고 결론을 냈습니다.

짧고 친절했던 교류끝에 Turner는 제안을 거절했습니다. 그의 목표는 우리와 달랐습니다. 우리는 언어의 기능에 대한 연구를 위해 기존의 목적과는 다른 혀태로 사용될 수 있는 언어를 원했습니다. 특히 우리는 누구나 언어를 확장, 수정, 구현, 구축 그리고 배포 할 수 있는 자유를 추구했습니다. 대조적으로 TurnerMiranda를 완벽한 이식성을 갖춘 단일 언어 표준을 유지하길 원했습니다. 또한 그는 Miranda의 여러 변형 언어가 존재하기를 원하지 않았고 우리가 새로운 언어를 Miranda와 구분하여 두 가지 언어가 혼동되지 않을 것을 요구했습니다. Turner는 위원회에 참석하는 것을 거절하였습니다.

좋든 나쁘 든간에 이것은 중요한 갈림길 이었습니다. 새로운 언어 디자인의 모든 세부 사항을 작업해야 한다는 의미였지만, 언어 설계의 여러 측면에 대한 근본적인 접근 방식을 자유롭게 고려할 수 있었습니다. 예를 들어 Miranda에서 시작했다면 우리는 Typeclasses를 개발하지 않았을 것 같았습니다. 그럼에도 불구하고, HaskellMiranda에게 상당한 빚을 지고 있습니다.

Turner가 우리에게 미란다 사용을 허용하지 않는다는 것을 알게되자 런던의 유니버시티 칼리지에서 호스팅 된 메일링 리스트 fplangc@cs.ucl.ac.uk를 사용하여 활발한 이메일 토론이 빠르게 진행되었습니다. Jones는 교수진이었습니다. 전자 메일 목록 이름은 원래 언어에 대한 이름이 없기 때문에 원래 FPLang 위원회라고 불렀습니다. 우리가 언어를 명명한 후에 "Haskell 위원회"(Haskell Committee)라고 부르기 시작했습니다.

2.4 The first meetings

Yale에서 1988년 1월 9일에서 12일까지 개최 된 첫 번째 모임에서 Hudak은 교수였고, 모임의 첫 번째 순서는 언어에 대한 다음 목표를 수립하는 것이 었습니다.

  1. 대규모 시스템 구축을 비롯하여 교육, 연구 및 응용 프로그램에 적합해야합니다.
  2. 그것은 formal syntaxsemantics를 온전하게 기술 및 출판되어야 한다.
  3. 자유롭게 이용할 수 있어야 합니다. 누구든지 해당 언어를 구현하고 원하는 사람에게 배포 할 수 있어야합니다.
  4. 더 많은 언어 연구를 위한 기초 자료로 활용 되어야 합니다.
  5. 새로운 제안은 폭 넓은 합의를 통해 이뤄저야 합니다.
  6. functional programming languages의 불필요한 다양성을 줄여야 합니다. 보다 구체적으로 말해서 OL에 기초를 두기로 합의했습니다.

마지막 두 가지 목표는 우리가 새로운 영역을 개척하기 보다는 언어를 보수적인 형태로 유지하기로 했다는 사실을 반영합니다. 우리는 아이디어에 관한 합의를 구체화하고 단일한 형태로 통합하는 것 이상을 진행하기로 하였습니다.

이 모든 목표들이 실현 된 것은 아닙니다. 우리는 OLHaskell에 명시적으로 적용한다는 생각을 버렸습니다. 특히 교육, 연구 수업의 적합성, 형식적인 의미를 개발하지 못했습니다.

위원회는 다음과 같은 합의 프로세스를 만들었습니다.

  1. 토론 할 주제를 결정하고 각 주제에 "lead person"을 지정하십시오.
  2. "lead person"은 자신의 주제를 요약하여 토론을 시작합니다. 특히 OL이 어떻게 하는지에 대한 설명하고, 더 나은 대안이 없는 경우 OL을 기본으로 합니다.
  3. 필요한 경우 연구. 휴식, 개별 토론 및 글쓰기를 장려합니다.
  4. 일부 문제는 해결되지 않을 것입니다! 그러한 경우 최종 결의안을 위한 조치 항목을 마련해야 합니다.
  5. 어리석은 것처럼 보일 수도 있지만 적어도 한 가지가 해결 될 때까지 모임을 연기해서는 안됩니다.
  6. 협조와 타협하는 자세가 중요합니다.

위의 다섯 번째 항목은 중요했습니다. 왜냐하면 어떤 언어의 진화에서 작지만 중요한 이름이 부여되는 순간이기 때문입니다. Yale 회의에서 우리는 이름을 선택하기 위해 다음과 같은 과정 (Wadler가 제안한)을 사용했습니다.

누구나 칠판에 쓰여진 하나 이상의 언어 이름을 제안 할 수 있습니다. 이 과정이 끝날 때, Semla, Haskell, Vivaldi, Mozart, CFL (Common Functional Language), Funl 88, Semlor, Candle, Fun, David, Nice ML Nouveau (또는 Miranda Nouveau 또는 LML Nouveau, 또는 ...), Mirabelle, Concord, LL, Slim, Leval, Curry, Frege, Peano, Ease, PortlandHaskell B Curry 등의 다양한 이름에 관한 토론이 끝난 후 각 사람은 그가 싫어하는 이름을 자유롭게 쓸 수 있었습니다. 우리가 끝났을 때, 한가지 이름이 남았습니다.

그 이름은 수학자이자 논리학자인 ``HaskellB. 커리(Haskell B. Curry)에게 경의를 표하여 "카레 (Curry)"를 생각하였으나 더 깊은 토론을 거쳐 새로운 언어의 이름 인 Haskell에 정착했습니다. 나중에 이것이 Pascal 또는 Hassle과 너무 쉽게 혼동되었다는 것을 깨달았습니다!

HudakWise는 커리의 미망인 인 Virginia Curry에게 남편의 이름을 사용할 수 있는지 물어보았습니다. Hudak는 나중에 그녀의 집을 방문하여 거기에 머물렀던 사람들에 관한 이야기를 들었습니다 (예 : ChurchKleene). 그녀의 논평은 "당신도 알다시피, Haskell은 실제로 Haskell이라는 이름을 결코 좋아하지 않았다."였습니다.

글래스고 대학에서 1988년 4월 6일에서 9일까지 개최된 회의를 통해서 functional programming languages 그룹이 급성장하였습니다. 이 회의에서 주요한 많은 결정이 내려졌습니다. HudakWadler가 첫 번째 Haskell 보고서의 편집자가 되었고, 보고서 이름은 "Report on the Programming Language Haskell, A Non-strict, Purely Functional Language"로 정해졌고, 이 보고서는 "Report on the Algorithmic Language Scheme"에 영향을 받았습니다.

'80년대는 functional programming 연구를 수행하는 흥미 진진한 시기였습니다. 이러한 사례를 보여주는 한 가지 사실은 기능 개발에 관한 IFIP Working Group 2.8John Williams(IBM Almaden의 John Backus와의 오랜 협력자)의 노력 덕분입니다.

2.5 Refining the design

얼굴을 맞대고 처음 만난 후, email을 사용해서 상세한 언어 설계 및 개발이 이루어졌습니다. Haskell 개발에 대한 간단한 타임라인은 아래와 같습니다.

  • 1987년 9월. 오리건 주 포틀랜드 FPCA에서의 최초 회의를 진행했습니다.
  • 1990년 4월 1일. Haskell 버전 1.0 보고서는 HudakWadler에 의해 편집되고 125 페이지로 출판되었다. 동시에, Haskell 메일 링리스트가 시작되었고, 모두에게 공개되었다. Haskell에 관한 모든 논의는 공개적으로 진행되었지만 여전히 위원회에서 결정을 내렸습니다.
  • 1991년 8월 Haskell 버전 1.1 보고서는 Hudak, Peyton JonesWadler가 편집하여 출판(153 페이지) 되었습니다. John Petersonhaskell.org 도메인을 등록하고, Yale에서 서버와 웹 사이트를 개설했습니다.
  • 1996년 5월. Haskell 버전 1.3 보고서가 출판되었으며 HammondPeterson이 편집했습니다. 기술적인 변화의 관점에서, Haskell 1.3은 Haskell의 1.0 이후 가장 중요한 릴리스였습니다.
  • 1997년 4월. PetersonHammond에 의해 편집 된 Haskell 버전 1.4 보고서(139 + 73 페이지)가 출판되었습니다.
  • 1999년 2월 Haskell 98 보고서가 출판되었습니다.
  • 1999-2002 1999년 Haskell 메일 링리스트를 읽는 모든 사람이 참여할 수 있게되었습니다. 그러나 Haskell이 널리 사용됨에 따라 작은 결함이 발견되었으며 보고서의 모호함도 보고되었습니다. Peyton Jones의 역할은 BDLM(온화한 언어 독재자)가 되었습니다.
  • 2002년 12월 수정된 Haskell 98 보고서가 발간됩니다. 케임브리지 대학 출판부는이 보고서를 책으로 출판하였지만, 전체 텍스트가 온라인상에서 이용 가능하고 누구든지 자유롭게 사용할 수 있다는 것에 동의했습니다.
  • Haskell 98이 나왔을 때 Haskell은 이미 세상에 나온지 8년이 지났음에도 불구하고, Haskell 98이 처음 발표 된 후 4년이 지난 후에 언어 명세가 변경(shake down) 되었습니다. 언어 디자인은 느린 과정입니다!

2.6 Was Haskell a joke?

Haskell 보고서의 초판은 1990년 4월 1일 만우절에 출판되었습니다. 그 이후에도 만우절은 계속해서 이어졌습니다. 이 모든 것이 시작된 것은 Haskell 보고서의 편집자의 역할이 스트레스를 주는 다소 어려운 시기였습니다. Hudak은 위원회에 메세지를 보냈고, 그는 또한 음악 분야에서 경력을 쌓기 위해 Yale을 그만두기도 했습니다. David Wise는 즉각 Hudak에게 전화를 걸어 결정을 재고 해달라고 호소했습니다.

그 이후 만우절 농담이 이어졌습니다. 대부분은 Haskell 웹 사이트에 있는 haskell.org/humor에 설명되어 있으며, 여기서는 흥미로운 것들을 요약해 놓았습니다.

  1. 1993년 4월 1일, Will PartainHaskell의 좋은 아이디어와 Perl의 훌륭한 아이디어를 결합한 Haskerl라는 Haskell 확장에 대한 훌륭한 발표문을 썼습니다. 기술적으로 상세하고 진지한 문체는 그것을 믿을만한 것으로 만들었습니다.
  2. Partain의 잘 쓰여진 장난에 대한 여러 답변은 똑같이 우스꽝스러운 것으로 Hudak이 작성한 것도 있습니다. "최근 HaskellYale 의대의 실험에 사용되었습니다. 그것은 heart-lung 기계를 제어하는 C 프로그램을 대체하기 위해 사용되었습니다. C 프로그램보다 Haskell 프로그램이 훨씬 강력했기 때문에 아마도 십여명의 생명이 구했다고 병원은 추정했습니다. 이에 대해 Nikhil은 다음과 같이 썼습니다. "X-Ray 장비의 소프트웨어 결함 때문에 많은 의료 사고를 겪었습니다. 그래서, 그들은 신뢰성을 위해 Haskell에서 코드를 재작성하기로 결정했습니다. 과실은 이제 0으로 떨어졌고, 그 이유는 새로운 X-Ray 촬영을 하지 않았기 때문입니다."
  3. 1998년 4월 1일 John PetersonSun MicrosystemsJava 사용에 대해 Microsoft를 고소했기 때문에 MicrosoftHaskell을 주 소프트웨어 개발 언어로 채택하기로 결정했다는 가짜 보도 자료를 썼습니다. 역설적이게도, 이 보도 자료 이후 얼마 지나지 않아 Peyton JonesGlasgow에서 CambridgeMicrosoft Research로 옮겼습니다. 그 당시 Peterson은 당시에는 알지 못했던 사건이었습니다. Microsoft는 실제로 다른 언어를 지원함으로써 Java에 응답했지만 Haskell이 아닌 C#입니다. 그러나 C#polymorphic typesLINQ(Language Ingrated Query)는 Haskell 및 기타 함수형 언어에 많은 영향을 받았습니다. LINQ의 수석 디자이너 인 Erik MeijerLINQHaskellmonad comprehensions에 직접적으로 영향을 받았다고 말합니다.
  4. 2002년 4월 1일, Peterson은 "개발자가 재무 스캔들의 하단에 위치하다!"라는 또 다른 가짜지만 즐겁고 타당한 기사를 썼습니다. 이 기사는 Peyton JonesHaskell을 사용하여 금융 계약을 평가하는 연구(Peyton Jones et al., 2000)에서 Enron의 초라한 금융 네트워크를 해결 할 수 있었다는 내용입니다. Peyton Jones는 다음과 같이 인용합니다. "정말 간단합니다. 가치가 주가에서 비롯되고 주식 가치가 계약에 달려 있다는 계약을 쓴다면 우리는 가장 최하위가 됩니다. 그래서 결국 엔론은 궁극적으로 전혀 가치가 없는 일련의 복잡한 계약을 만들었습니다."

3. Goals, principles, and processes

이번 절에선 우리의 생각, 선택, 그리고 그것들을 이끌어 낸 과정의 중요한 기반이 되었던 원칙에 대해서 설명합니다.

3.1 Haskell is lazy

LazinessHaskell의 설계에 기여한 다양한 모임을 하나로 묶은 중요한 주제였습니다. 기술적으로 Haskellnon-strict semantics을 가진 언어입니다. lazy evaluationnon-strict한 언어를 구현하는 기법 중 하나입니다. 그럼에도 불구하고 laziness라는 용어는 non-strict 보다 명료하고, 뚜렷하기 떄문에 우리는 Haskelllaziness라 설명하였습니다. 구현 기술을 구체적으로 언급 하는 부분에선 LispML과 같은 언어의 call-by-value와 구별해서 call-by-need라는 용어를 사용할 것입니다.

80년대 중반까지 lazy functional programming에 대한 매력을 잘 이해하고 있었습니다. Hughes의 논문 <>는 lazy programming에 대한 영향력 있는 선언문에 영향을 받은 것이고, Haskell의 초기 설계와 일치했습니다(Hughes는 1984년 옥스포드 대학에서 취직했을 때 인터뷰에서 처음 발표했으며, 1989년에 출판되기 전에 비공식적으로 배포되었다(Hughes, 1989)).

Laziness는 비용(cost)이 듭니다. Call-by-need는 일반적으로 개별적으로 평가가 진행되지 않도록 지연을 요구하고 값을 겹쳐 사용해야 하는 추가 부담 때문에 call-by-value보다 효율적이진 않습니다. 해당 비용에 대한 평가는 Haskell이 설계되었을 당시에 충분히 받아들여졌습니다.

훨씬 더 중요한 문제는 숙련된 프로그래머조차도 lazy programs의 동작을 예측하는 것이 매우 어렵습니다. 이러한 이유로 Haskellseqstrict data types(SASLMiranda에서 수행 된 것처럼)과 같은 몇 가지 기능을 추가하였습니다. strict한 언어에 lazy가 적용되었습니다(Wadler et al., 1988). 결과적으로 strict/lazy에 대한 분열은 결정되어졌고 각자 다른 쪽의 가치를 인식하였습니다.

3.2 Haskell is pure

laziness의 직접적으로 말하자면 수요 중심(demand-driven) 이라 할 수 있습니다. 결과적으로 I/O에 영향을 받거나 함수 호출로 인한 side effects가 거의 불가능해졌다. 따라서 Haskell은 순수한(pure) 언어입니다. 예를 들어, 함수 fInt -> Int 유형을 가지고 있다면 f가 변수를 사용하거나 I/O를 수행하지 않는다는 것을 확신 할 수 있습니다. 간단히 말해서, f는 실제로 수학적 의미에서의 함수입니다. 몇번을 호출해도 (f 3)은 같은 값을 반환합니다.

laziness를 선택하고 나면 순수한 언어는 피할 수 없습니다. 역은 성립하지 않지만 대부분의 순수한 프로그래밍 언어는 laziness 합니다. 왜냐하면 call-by-value를 선택한 언어의 경우 side effects를 거의 허용하고 있기 때문입니다.

Purity는 큰 결정이며 거의 모든 곳에 영향을 미칩니다. side effects를 허용하는 것은 의심할 여지없이 편리함을 제공합니다. side effects가 없기 때문에, Haskell의 입출력은 처음에는 힘들고, 서툴고 당혹스럽습니다. 이러한 불편함은 궁극적으로 monadic I/O로 이어졌고 아주 중요한 기여로 간주됩니다.

궁극적으로 pure language (with monadic effects)가 프로그램을 작성하는 가장 좋은 방법인지 여부는 여전히 열려있는 근본적이고 우아한 질문이지만 강력하고 우아한 설계의 동기(motivate)로 작용합니다. 돌이켜 보면 laziness의 가장 큰 단일 장점은 laziness 그 자체가 아니라 우리를 순수하게 유지시켜서 Monadencapsulated state를 제공해서 더 많은 생산적인 작업을 하도록 동기를 부여했다는 점이라 할 수 있습니다.

3.3 Haskell has type classes

lazinessHaskell의 디자이너를 하나로 모으는 것이었지만 Haskell의 가장 분명한 특성으로 간주되는 type classes 일 것입니다. Type classes는 1988년 2월 24일 fplangc 메일 링리스트로 보내진 메시지에서 Wadler에 의해 Haskell위원회에 소개되었습니다.

초기에 타입 클래스는 수치 연산자의 오버로딩과 평등이라는 좁은 문제에 의해 동기 부여되었습니다. 이러한 문제는 MirandaSML에서 완전히 다른 방식으로 해결되었습니다.

SML은 내장 숫자 연산자에 대한 오버로드를 사용하여 호출 시점에서 해석됩니다. 이로 인해 오래된 숫자로 새로운 숫자 연산을 정의하는 것이 어려워졌습니다. 예를 들어, 곱셈의 측면에서 정사각형을 정의하고 싶다면, 정수 및 부동 소수점과 같이 각 숫자 유형마다 다른 버전을 정의해야합니다. Miranda는 정수라고 불리는 단일 숫자 유형 (num이라고 불림)을 피함으로써이 문제를 피했습니다. 정수는 무한 크기의 정수와 배정 밀도 수를 결합한 것으로, 필요할 때 int를 자동으로 float로 변환합니다. 이것은 편리하고 유연하지만 정적 타이핑의 몇 가지 장점을 희생합니다. 예를 들어 Miranda에서는 대부분의 언어에서 모듈러스 연산자 mod가 정수 모듈에 대해서만 의미가 있지만 표현식 (mod 8 3.4)은 유형에 맞습니다.

또한 SML은 원래 오버로딩을 사용하여 동등 함을 나타 내기 때문에 목록 및 값을 취한 다형 함수를 정의 할 수 없으며 값이 목록의 일부 요소와 동일하면 true로 되돌립니다. (이 함수를 정의하기 위해, 추가 인자로서 equality-testing 함수를 사용해야 할 것입니다.) Miranda는 단순히 다형성 타입을 평등하게했지만 함수 타입에 대해 평등성을 정의했습니다 (런타임에 오류가 발생했습니다). (추상화 장벽을 침해하는 등 평등성에 대한 기본 표현을 비교). 최신 버전의 SML에는 다형성 평등이 포함되었지만 동등성이 정의 된 유형 (즉, 함수 유형 또는 추상 유형이 아닌)에 대해서만 범위가 지정된 특수 "동등 유형 변수"(a 대신 a로 작성)가 도입되었습니다.

유형 클래스는 이러한 두 가지 문제에 대해 통일 된 해결책을 제공했습니다. 그들은 SML에서 평등 유형 변수의 개념을 일반화하여 주어진 연산 집합 (예 : 수치 연산 또는 평등)을 가진 유형의 "클래스"개념을 도입했습니다.

타입 클래스 솔루션은 우리에게 매력적이었습니다. 왜냐하면 어떤 대안보다도 더 원칙적이고 체계적이며 모듈화 된 것처럼 보였기 때문입니다. 그것의 다소 과격하지만 검증되지 않은 성격에도 불구하고, 그것은 찬사에 의해 채택되었습니다. 우리는 우리가 무엇을 위해 스스로를 기다리고 있는지 알지 못했습니다!

Wadler는 Haskell 회의 중 한 후에 Joe Fasel과 대화하면서 형식 수업을 생각했습니다. Fasel은 다른 생각을 염두에 뒀지 만 과부하가 기능의 유형에 반영되어야한다는 핵심 통찰력을 가진 사람이었습니다. WadlerFasel이 염두에두고있는 것을 오해했고, 타입 클래스가 탄생했습니다! 와들러의 학생 Steven Blott은 형식 규칙을 공식화하는 데 도움을 주었으며, 박사 학위 논문에 대해 시스템이 완전하고 완전하며 일관성이 있음을 입증했습니다(Wadler and Blott, 1989; Blott, 1991). 비슷한 생각이 Stefan Kaes(Kaes, 1988)에 의해 독립적으로 형성되었다.

우리는 6 절에서 유형 - 클래스 접근법의 세부 사항과 결과 중 일부에 대해 자세히 설명한다. 한편, Haskell 언어의 근본적이고 광범위한 측면의 다소 우발적 인 성격을 반영하는 것은 유익하다. WadlerBlott가 언어 디자인이 여전히 유동적 인 순간에이 핵심 아이디어를 산출 한 것은 타이밍의 행복한 우연이었습니다. 우리는 시도되고 검증 된 합의를 구현하는 암묵적인 목표에 직접적으로 모순되는 가운데, 거의 논의하지 않고 채택되었습니다. 그것은 처음부터 그것을 채택하는 우리의 초기 이유를 극적으로 초과하는 광범위한 결과를 낳았습니다.

3.4 Haskell has no formal semantics

우리의 명확한 목표 중 하나는 정식으로 정의 된 유형 시스템(formally defined type system)과 의미론(semantics)을 가진 언어를 만드는 것이 었습니다. 우리는 프로그래밍 언어 설계에서 수학적인 방법을 도입하는 것에 많은 관심이 있었습니다. 우리는 ML로부터 많은 영감을 받았습니다. ML은 언어에 대한 완전한 formal definition을 할 수 있음을 보여 주었고, Standard ML(Milner and Tofte, 1990; Milner et al., 1997)이 그 영광의 자리를 차지했습니다.

그럼에도 불구하고 우리는 이 목표를 달성하지 못했습니다. Haskell Report는 일반적인 언어 정의의 전통을 따르고 있습니다 : 그것은 조심스럽게 영어를 사용합니다. 언어의 일부 (예 : 패턴 매칭의 중요성)는 작은 "핵심 언어"로의 번역에 의해 정의되지만, 후자는 결코 정식으로 지정되지 않습니다. 후속 논문은 Haskell의 좋은 부분, 특히 그 유형 시스템 (Faxen, 2002)을 기술하고 있지만, 모든 것을 설명하는 문서는 하나도 없다. 왜 안돼? 확실히 Haskell위원회의 의식적인 선택 때문이 아닙니다. 오히려 그것은 가장 절박한 일이 아닌 것 같습니다. 아무도 그 일을 맡지 않았고, 실제로 언어 사용자와 구현자는 그것 없이는 완벽하게 관리하는 것처럼 보였습니다.

실제로 실제로 Haskell의 정적 의미론 (즉, 유형 시스템의 의미론)은 대부분의 복잡성이있는 부분이다. 형식적인 정적 의미를 가지지 않은 결과는 아마도 컴파일러 작성자에게 어려운 일이며 때로는 서로 다른 컴파일러간에 약간의 차이가 생깁니다. 그러나 사용자가 프로그램 유형을 검사하면 정적 의미론에 대한 염려가 거의 없으며 정적 의미론에 대해 공식적인 이유가 거의 필요하지 않습니다.

다행히 Haskell의 동적 의미는 비교적 간단합니다. 사실, Haskell의 디자인 과정에서 우리는 Haskell의 의미가 정식으로 쓰이지 않아도, 우리 모두가 Haskell의 의미가 무엇인지 알았 듯이, 디자인 옵션을 논의하기 위해 의미 론적 의미에 의지했습니다. 이러한 추론은 "하단"(오류 또는 비 종결을 나타내며 패턴 매칭, 함수 호출, 재귀 적으로 정의 된 값 등에서 게으른 언어에서 빈번하게 발생 함)에 대한 추론에 특히 유용합니다.

아마도 더 중요한 것은 Haskellthe dynamic semanticsHaskell의 순수함 덕분에 formal denotational 또는 operational semantics보다 적용하기 훨씬 쉬운 "equational reasoning"을 제공합니다. "equational reasoning"에 대한 이론적 근거는 lambda calculus (β-and η-reduction)primitive operations (so-called δ-rules)에서 파생(derives)됩니다. 유도(및 공동 유도(co-induction)) 원리와 결합된 강력한 추론 방법입니다. Haskell에서의 "equational reasoning"은 문화의 일부이며 모든 Haskell 프로그래머가 받는 교육의 일부입니다. 결과적으로 formally specified semantics가 부족함에도 불구하고 Haskell에서 다른 언어보다 correctness propertiesprogram transformations에 대한 더 많은 증거가 있습니다. 그러한 증명은 대개 Haskellη-reduction과 같은 사용 된 기본 단계 중 일부가 실제로 공식적인 의미를 보존하지 않는다는 사실을 무시하지만 (적절한 상황에서) 올바른 조건에선 유효합니다(Danielsson et al., 2006)!

3.5 Haskell is a committee language

Haskell은 위원회에서 설계한 한 언어이며, 일반적인 통념상 위원회에서 설계한 언어는 어색한 타협으로 가득 차 있다고 말합니다. Tony Hoare가 Haskell 위원회에 보낸 기억에 남는 편지에서는 Haskell이 "성공할 운명"이라고 단호하게 말했습니다.

그러나 앞선 결점 때문에 Haskell은 종종 "아름다운" 또는 "우아한" 심지어는 "쿨"한 것으로 묘사됩니다. 이것은 보통 위원회 설계와 거의 관련 없는 말입니다. 어떻게 이런 일이 생겼을까요? 이 질문에 대해 우리는 다음과 같은 몇 가지 요인을 확인했습니다.

  • 초기 상황이 매우 호의적이였습니다. 우리 모두 Haskell이 필요했습니다.
  • 수학적 우아하함을 추구했고 이러한 결정으로 언어 기능이 복잡해지는 것을 확실하게 막았습니다.
  • 이메일을 사용한 회의뿐만 아니라 대면회의를 사용해서 의사소통을 진행했습니다.
  • 설계 과정에서 매 순간마다 한 두명 위원이 The Editor의 역할을 수행고, 책임과 권한을 올바르게 수행했습니다. 그는 보고서의 관리인이었으며 결론을 구체화 할 책임이 있었습니다.
  • 설계 과정에서 매 순간에 위원회의 한 구성원(반드시 편집자일 필요는 없음)이 Syntax Czar 역할을 했습니다. Czar는 syntactic 문제들에 대해서만 단호한 결정을 할 수 있는 권한을 부여 받았습니다. 모든 사람들은 구문을 논의하는 데 너무 많은 시간을 할애한다고 말지만 많은 사람들이 람다에 대한 선호하는 기호로 끝나지 않는 싸움이 될 것입니다. Syntax Czar는 그러한 논쟁을 끝내기 위한 우리만의 방식이었습니다.

3.6 Haskell is a big language

위원회의 중요한 논쟁 주제는 아름다움과 효용간의 경쟁이었습니다. 한편으로 우리는 간단하고 우아한 언어를 열정적으로 설계하려고 했습니다. "프트웨어 설계를 구성하는 데에는 두 가지 방법이 있다. 한가지 방법은 아주 단순하게 만들어서 명백히 결함이 없게 된다. 그리고 다른 방법은 너무 복잡하게 만들어서 명백한 결함이 없게 된다"(C.A.R. Hoare) 한편, 우리는 Haskell이 교수 및 실제 응용 프로그램 모두에 유용한 언어가되기를 정말로 원했습니다.

그러나 Richard Bird는 1988년에 위원회를 사임하였습니다. 당시 그는 "fplang에 제출 된 많은 자료와 의견에 대한 기록에서 단순성, 증명의 용이성, 우아함의 원칙이 무너질 것 같은 심각한 위험이 있다. 제안 된 것 중 많은 부분이 부족하고, 역행적이고, 괴상하기 때문에 결과가 엉망이 될 가능성이 큽니다. 우리는 Lisp(10년 넘게 pursuit of functional programming의 발전을 저해한 언어)와 관련없는 구문으로 되돌아 가야한다. 우리는 규모가 커질 때 작은 프로그램을 위한 '미학적' 구조가 매력을 잃어 버리기 때문에 '큰'프로그램을 설계하도록 촉구한다. 깊게 중첩 된 구조를 가진 큰 wher 절을 허용 할 것을 촉구합니다. 간단히 말해서, 기존 프로그래밍과 구별되는 functional programming의 한 가지 특징을 버리고 21세기의 생존을 보장 할 수 있습니다"

결국,위원회는 전면적 인 복잡성을 전심으로 받아들였습니다. 예를 들어, 모순된 표현방법, 복잡한 클래스 선언 등을 수정하였습니다. 우리는 purely functional programming의 우아한 핵심은 상처받지 않고 살아남았다고 생각합니다. 진정한 타협이 이루어진 장소를 골라야한다면, monomorphism 제한과 seq로 인한 parametricity, curryingsurprive pairing의 손실이 될 것입니다.

3.7 Haskell and Haskell 98

연구를 위해 Haskell을 사용할 땐 안정적으로 동작하고, 개선을 필요로 합니다. 처음에는 발전를 중시하고 있었습니다. Haskell 보고서의 각 버전의 취지는 다음과 같이 말합니다. "위원회는 Haskell이 언어 설계의 미래 연구의 기초가 될 것으로 기대하고 있습니다. 우리는 언어의 확장과 변형이 실험적인 특징을 반영할 수 있기를 바라고 있습니다." 그러나 Haskell의 인기가 높아짐에 따라 언어의 설계 변경이나, 우리의 계획이 무엇인지에 관한 질문이 나오기 시작했습니다. "나는 Haskell에 대한 책을 쓰려고 생각하고 있습니다. 그런데, 언어가 변화하는 경우 책을 쓸 수 없습니다."라는 것이 전형적인 예라 할 수 있습니다.

위원회는 이러한 요청에 대응하여 간단하고 이해하기 쉬운 해결책을 제시했습니다. Haskell 98이라는 특정한 버전을 지정하고 Haskell 98을 무기한 지원할 것을 약속했습니다. 우리는 Haskell 98을 합리적이며 보수적인 설계를 유지하기로 하였습니다. 예를 들면, 당시에 multi-parameter type classes가 널리 사용되고 있었지만, Haskell 98single-parameter type classes만 지원했습니다(Peyton Jones et al., 1997).

Haskell 98(비공식) 표준화는 또 다른 이유를 위해 중요한 전환점이었습니다. Haskell 위원회가 해산 한 순간이었습니다. Haskell 커뮤니티에는 언어 기능을 위한 수많은 제안을 포함한 방대한 양의 혁신 활동이 있었습니다(그리고 앞으로도 계속 될 예정입니다). 그러나 위원회는 특별한 선택을 하는 것이 아니라 천개의 꽃이 피고, 어떤 생물이 살아남는지 지켜봐야 한다고 결정했습니다. 위원회의 작업을 종료하고 거대한 메일 저장소를 안전하게 저장하였습니다.

우리는 Haskell 98 이외의 Haskell의 변형을 저지하려는 시도를 하지 않았습니다. 오히려 우리는 명시적으로 언어의 발전을 장려했습니다. 이 명명법은 "Haskell 98"은 안정된 언어의 변형이며 자유 분방한 종류의 모든 구현체를 "Haskell"이라고 말할 수 있도록 장려하고 있습니다.
위원회가 존재하지 않기 때문에 Haskell은 서로 다른 방식으로 발전하고 있습니다.

  • Haskell은 수천 명의 사용자와 성숙한 언어로되어 있기 때문에, 현실의 언어가 직면하는 규모와 복잡성 문제를 해결해야 합니다. 따라서 외부 기능을 도입하기 위한 라이브러리 인터페이스, 풍부한 컬렉션, 동시성 예외 등 실질적으로 지향 된 기능이나 자원의 범위가 확대되고 있습니다.
  • 동시에 언어는 특히 타입 시스템과 메타 프로그래밍 분야에서 고급 언어 디자인 아이디어를 탐구하기 위한 매우 효과적인 실험실 역할을 하고 있습니다. 이러한 아이디어는 Haskell을 기본 언어로 한 연구 논문의 수와 Haskell 구현 논문 모두에 나타나고 있습니다.

Haskell이 지금까지 개발의 두 가닥 사이의 긴장을 잘 관리해 온 것은 우연의 미덕 때문입니다. Haskell은 그다지 성공하지 않습니다. Java와 같은 급속한 성공은 많은 사용자를 획득할 수 있으며, 동시에 표준 사용자 그룹 및 언어의 명세가 잘못 되 ㄹ수 있다는 점이고, 대조적으로 Haskell 커뮤니티는 민첩하게 변화를 흡수하고 있습니다.

3.8 Haskell and Miranda

Haskell이 태어난 시점에서 가장 성숙하고 널리 사용되고있는 non-strict functional languageMiranda였습니다. Miranda는 1983 년에 설립 된 David TurnerResearch Software Limited에서 개발 되었고, Hindley-Milner(Milner, 1978)에 의한 lazy functional programming을 상용 도메인에 도입하는 것을 목표로 하였습니다. 1985년에 처음 출시 되고 1987년과 1989년에 개선된 Miranda는 뛰어난 구현, REPL, 다양한 textbook(대표적인 것은 Bird and Wadler 1988)을 가지고 있었습니다. 학술 라이센스 및 상용 라이센스가 거론되었습니다. 1990년대 초 250개 대학과 20개국의 50개 회사에 Miranda가 도입되었습니다.

따라서 Haskell의 디자인은 Miranda의 영향을 강하게 받았습니다. 당시 MirandaHindley-Milner형 시스템과 algebraic data types을 가진 non-strict, purely functional language를 표방했습니다. 그것은 바로 Haskell이 기대했던 언어의 종류였습니다. 그 결과, 기본적인 접근(purity, higher order, laziness, static typing)과 구문적인 모양과 관련되어 두 언어 사이에 많은 유사점이 있습니다. the equational style of function definitions, pattern matching, guards, where clauses, algebraic types, the notation for lists and list comprehensions, ML의 int*bool형태가 아닌 (num,bool) 형식, capitalisation of data constructors, lexically distinguished user-defined infix operators, the use of a layout rule, 그리고 the naming of many standard functions등이 대표적인 예라 할 수 있습니다.

Miranda와 현저한 차이가 있습니다. 예를 들어, garud 위치, 표현식, 데이터 타입 선언 구문이 다릅니다. 타입 생성자와 데이터 생성자, 변수에 숫자 식별자를 사용 가능하다. 사용자 정의 연산자의 구별(x $op yx 'op' y), 레이아웃 규칙도 차이를 보입니다. 근본적으론 Haskell은 모듈 시스템을 대신 사용하여 추상 데이터 타입을 채용하지 않았습니다. 모나드 I/O가 추가되었습니다. Hindley-Milner type system, 특히 type classes에서 차이를 보입니다.

오늘 Miranda는 주로 Haskell로 대체했습니다. Haskell 책은 정기적으로 등장하고 있습니다만, Miranda의 교과서는 1995년에 출판되었습니다. Research Software Limited는 학술 라이센스를 상용 라이센스보다 저렴하게 제공했다. 모두 무료는 아니었지만, Haskell은 대학 그룹에 의해 제작되고 있으며, 학술 및 상업 이용자도 자유롭게 이용할 수 있다. 또한 MirandaUnix에서만 작동하고 Windows 버전이 존재하지 않았다.

Miranda는 뛰어난 구현을 제공했지만, Haskell의 구현은 보다 신속하게 개선되었습니다. 작은 회사가 따라 잡기는 어려웠습니다. HugsMiranda에 제공된 REPL을 Haskell에게 주었습니다. 무어의 법칙은 Haskell의 느린 컴파일러를 개선했습니다. 이 논문에서는 Haskell이 중요한 새로운 아이디어를 가지고 있었다고 말합니다. 1990년대 중반까지 HaskellMiranda 실제 프로그래밍을 위한 훨씬 더 현실적인 선택이었다.

Miranda의 독점적 지위는 학계에서 보편적 인지도를 얻고 있지 못했습니다. Turner는 상표를 보호하기 Research Software Limited를 항상 서류에 기록했습니다. 이에 대응하여 몇 가지 초기 Haskell의 출판물에는 "Haskell은 상표가 없습니다"라는 각주가 포함되어 있었습니다. 당시 미란다의 라이센스 조건은 미란다의 구현을 배포하기 전에 라이센스 소유자에게 허락을 받아야했습니다. 하지만 Turner는 이러한 부채에 대해서 항의를 하지 않았습니다.

"혹시"라는 가정을 해보게 됩니다. TurnerMiranda를 공개했다면 어떻게 되었을까요? 80년대 중반에는 연구 커뮤니티와 그 지원을 받고있는 기업이 지원하는 lazy functional language를 기대해 볼 수 있었을까요? 비즈니스 모델을 발견 할 수 있었습니까? 역사는 어떻게 달라졌을까요?

Miranda는 물론 상업적, 연구용으로 실패하지 않았습니다. 많은 대학에서 채택된 잘 구현된 작고 우아한 언어로 functional language 보급을 촉직하는 것을 도왔습니다. 학문 분야를 넘어 여러 대규모 프로젝트(Major and Turcotte 1991; Page and Moe, 1993)에서 Miranda의 사용은 lazy functional language의 가능성을 보여주었습니다. Miranda는 오늘날에도 여전히 사용되고 있습니다. 아직도 일부 기관에서 진행하고 있으며, LinuxSolaris 구현체는 계속 제공되고 있습니다. Turner의 노력은 몇 년 후 Haskell의 일반적인 주제에 대한 관심과 발전에 지속적이고 가치있는 기여를 했습니다.