나는 파티에 늦게 온다는 것을 알고 있지만 여기에 두 가지 이론적 대답이 있었고, 씹을 수있는 실용적인 대안을 제공하고 싶었습니다. 그럼에도 불구하고 나는 현재 진행중인 프로젝트에 대해 Arrows 주제를 통해 최근에 강제 행진 한 Haskell 멍청한 친척으로 여기에 왔습니다.
첫째, Arrows에 도달하지 않고도 Haskell의 대부분의 문제를 생산적으로 해결할 수 있습니다. 일부 주목할만한 Haskellers는 진정으로 싫어하고 사용하지 않습니다 (자세한 내용은 여기 , 여기 및 여기 참조). 당신이 자신에게 "이봐, 난 필요 없어"라고 말하는 경우에, 당신이 진정으로 정확할 수 있음을 이해하십시오.
내가 처음 화살표를 배웠을 때 내가 화살표에 대해 가장 실망한 것은 주제의 튜토리얼이 필연적으로 회로의 비유를 위해 어떻게 도달했는지였습니다. 최소한 설탕을 넣은 품종 인 Arrow 코드를 보면 하드웨어 선언 언어와 전혀 흡사합니다. 입력은 오른쪽에 정렬되고 출력은 왼쪽에 정렬되며 모두 올바르게 연결하지 않으면 단순히 작동하지 않습니다. 나는 나 자신에게 생각했다 : 정말로? 우리가 끝난 곳입니까? 우리는 다시 한번 구리선과 납땜으로 구성된 언어를 완전히 고수준으로 만들었습니까?
내가 결정할 수있는 한 이것에 대한 정답은 실제로입니다. 현재 Arrows의 킬러 사용 사례는 FRP입니다 (Yampa, 게임, 음악 및 반응 형 시스템을 일반적으로 생각하십시오). FRP가 직면 한 문제는 다른 모든 동기식 메시징 시스템이 직면 한 것과 거의 같은 문제입니다. 관련 정보를 삭제하거나 스프링 누수없이 연속적인 입력 스트림을 연속적인 출력 스트림에 연결하는 방법입니다. 스트림을 목록으로 모델링 할 수 있습니다 (최근의 여러 FRP 시스템에서이 방법을 사용함). 입력 목록이 많은 경우 관리하기가 거의 불가능합니다. 현재로부터 자신을 격리시켜야합니다.
FRP 시스템에서 Arrows가 허용하는 기능은 네트워크로 기능을 구성하는 동시에 해당 기능에 의해 전달되는 기본 값에 대한 참조를 완전히 추상화하는 것입니다. FP를 처음 사용하는 경우 처음에는 혼란 스러울 수 있으며 그 의미를 흡수했을 때 마음이 번질 수 있습니다. 최근에는 함수를 추상화 할 수 있다는 아이디어와 [(*), (+), (-)]유형 유형 과 같은 목록을 이해하는 방법 만 이해했습니다 [(a -> a -> a)]. 화살표를 사용하면 추상화를 한 계층 더 밀어 낼 수 있습니다.
추상화하는 이러한 추가 능력은 그 자체의 위험을 수반합니다. 우선, GHC를 사용하여 유형 가정을 무엇을 해야할지 모를 경우 코너에 넣을 수 있습니다. 유형 수준에서 생각할 준비가되어 있어야합니다. 이것은 종류와 RankNType 및 기타 주제에 대해 배울 수있는 좋은 기회입니다.
또한 "Stupid Arrow Stunts"라고하는 몇 가지 예가 있습니다. 코더는 튜플을 사용하여 깔끔한 트릭을 보여주기 위해 Arrow 컴비 네이터에 도달합니다. (여기서 광기에 기여한 사소한 일이 있습니다.) 야생에서 만날 때 그러한 핫도그를 무시하십시오.
참고 : 위에서 언급했듯이 나는 상대 멍청한 놈입니다. 위의 오해를 공표 한 경우 언제든지 수정 해주세요.