Haskell의 대규모 디자인?

Haskell의 대규모 디자인? [닫은]

---

특히 Haskell에서 큰 기능적 프로그램을 설계 / 구조화하는 좋은 방법은 무엇입니까?

나는 많은 튜토리얼을 봤지만 (Write Yourself a Scheme이 가장 좋아하고, Real World Haskell이 가까운 두 번째)-대부분의 프로그램은 상대적으로 작고 단일 목적입니다. 또한 일부는 특히 우아하다고 생각하지 않습니다 (예 : WYAS의 방대한 조회 테이블).

이제는 다양한 소스에서 데이터를 수집하고, 정리하고, 다양한 방식으로 처리하고, 사용자 인터페이스에 표시하고, 유지하고, 네트워크를 통해 통신하는 등 더 많은 움직이는 부분이있는 더 큰 프로그램을 작성하고 싶습니다. 어떻게 할 수 있습니까? 코드가 읽기 쉽고 유지 관리가 가능하며 변화하는 요구 사항에 적응할 수있는 최상의 구조는 무엇입니까?

대규모 객체 지향 명령형 프로그램에 대한 이러한 질문을 다루는 많은 문헌이 있습니다. MVC, 디자인 패턴 등과 같은 아이디어는 관심사 분리 및 OO 스타일의 재사용 가능성과 같은 광범위한 목표를 실현하기위한 적절한 처방입니다. 또한 새로운 명령형 언어는 '성장에 따른 디자인'스타일의 리팩토링에 적합합니다. 초심자 의견으로는 Haskell이 적합하지 않은 것처럼 보입니다.

Haskell에 상응하는 문헌이 있습니까? 이 목적을 위해 함수형 프로그래밍 (모나드, 화살표, 응용 프로그램 등)에서 사용할 수있는 이국적인 제어 구조의 동물원은 어떻게 가장 잘 사용됩니까? 어떤 모범 사례를 추천 할 수 있습니까?

감사!

편집 (이것은 Don Stewart의 답변에 대한 후속 조치입니다) :

@dons 언급 : "모나드는 유형의 주요 아키텍처 디자인을 캡처합니다."

내 질문은 순수한 기능적 언어로 핵심 건축 설계에 대해 어떻게 생각해야 하는가?

여러 데이터 스트림 및 여러 처리 단계의 예를 고려하십시오. 데이터 스트림에 대한 모듈 식 파서를 데이터 구조 세트에 작성할 수 있으며 각 처리 단계를 순수 함수로 구현할 수 있습니다. 하나의 데이터에 필요한 처리 단계는 그 값과 다른 부분에 따라 다릅니다. 일부 단계는 GUI 업데이트 또는 데이터베이스 쿼리와 같은 부작용이 뒤따라야합니다.

데이터와 구문 분석 단계를 좋은 방식으로 연결하는 '올바른'방법은 무엇입니까? 다양한 데이터 유형에 대해 올바른 작업을 수행하는 큰 함수를 작성할 수 있습니다. 또는 모나드를 사용하여 지금까지 처리 된 내용을 추적하고 각 처리 단계가 모나드 상태에서 다음에 필요한 모든 것을 얻도록 할 수 있습니다. 또는 크게 별도의 프로그램을 작성하고 메시지를 보낼 수 있습니다 (이 옵션이별로 마음에 들지 않습니다).

그가 링크 한 슬라이드에는 '우리가 필요로하는 것들'글 머리 기호 : "디자인을 유형 / 함수 / 클래스 / 모나드에 매핑하기위한 숙어"가 있습니다. 관용구는 무엇입니까? :)

---

나는 Haskell의 Engineering Large Projects 와 XMonad 의 Design and Implementation 에서 이것에 대해 약간 이야기합니다 . 전반적으로 엔지니어링은 복잡성을 관리하는 것입니다. 복잡성 관리를위한 Haskell의 기본 코드 구조화 메커니즘은 다음과 같습니다.

유형 시스템

• 유형 시스템을 사용하여 추상화를 적용하고 상호 작용을 단순화합니다.
• 유형을 통해 키 불변성 적용
  • (예 : 특정 값이 일부 범위를 벗어날 수 없음)
  • 특정 코드는 IO를 수행하지 않고 디스크를 건드리지 않습니다.
• 안전 강화 : 확인 된 예외 (어쩌면 / 둘 중 하나), 혼합 개념 (Word, Int, Address)을 피하십시오.
• 좋은 데이터 구조 (지퍼와 같은)는 예를 들어 경계를 벗어난 오류를 정적으로 배제하기 때문에 일부 테스트 클래스를 불필요하게 만들 수 있습니다.

프로파일 러

• 프로그램의 힙 및 시간 프로필에 대한 객관적인 증거를 제공합니다.
• 특히 힙 프로파일 링은 불필요한 메모리 사용을 방지하는 가장 좋은 방법입니다.

청정

• 상태를 제거하여 복잡성을 크게 줄입니다. 순전히 기능적인 코드는 구성 적이므로 확장됩니다. 필요한 것은 코드 사용 방법을 결정하는 유형뿐입니다. 프로그램의 다른 부분을 변경할 때 이상하게 깨지지는 않습니다.
• "모델 / 뷰 / 컨트롤러"스타일 프로그래밍을 많이 사용합니다. 가능한 한 빨리 외부 데이터를 순전히 기능적인 데이터 구조로 구문 분석하고 해당 구조에서 작동 한 다음 모든 작업이 완료되면 렌더링 / 플러시 / 직렬화합니다. 대부분의 코드를 순수하게 유지

테스팅

• QuickCheck + Haskell Code Coverage는 타입으로 확인할 수없는 것들을 테스트하고 있는지 확인합니다.
• GHC + RTS는 GC에 너무 많은 시간을 소비하고 있는지 확인하는 데 좋습니다.
• QuickCheck는 또한 모듈에 대한 깔끔하고 직교적인 API를 식별하는 데 도움이 될 수 있습니다. 코드의 속성을 설명하기 어려운 경우 너무 복잡 할 수 있습니다. 코드를 테스트 할 수 있고 잘 구성 될 수있는 깨끗한 속성 집합을 얻을 때까지 리팩토링을 계속하십시오. 그렇다면 코드도 잘 설계되었을 것입니다.

구조화를위한 모나드

• 모나드는 유형의 주요 아키텍처 디자인을 캡처합니다 (이 코드는 하드웨어에 액세스하고이 코드는 단일 사용자 세션 등).
• 예를 들어 xmonad의 X 모나드는 시스템의 어떤 구성 요소에 어떤 상태가 표시되는지에 대한 설계를 정확하게 캡처합니다.

유형 클래스 및 실존 유형

• 추상화를 제공하기 위해 유형 클래스를 사용합니다. 다형성 인터페이스 뒤에 구현을 숨 깁니다.

동시성 및 병렬성

• par프로그램에 몰래 들어가 쉽고 구성 가능한 병렬 처리로 경쟁에서이기십시오.

리팩터링

• You can refactor in Haskell a lot. The types ensure your large scale changes will be safe, if you're using types wisely. This will help your codebase scale. Make sure that your refactorings will cause type errors until complete.

Use the FFI wisely

• The FFI makes it easier to play with foreign code, but that foreign code can be dangerous.
• Be very careful in assumptions about the shape of data returned.

Meta programming

• A bit of Template Haskell or generics can remove boilerplate.

Packaging and distribution

• Use Cabal. Don't roll your own build system. (EDIT: Actually you probably want to use Stack now for getting started.).
• Use Haddock for good API docs
• Tools like graphmod can show your module structures.
• Rely on the Haskell Platform versions of libraries and tools, if at all possible. It is a stable base. (EDIT: Again, these days you likely want to use Stack for getting a stable base up and running.)

Warnings

• Use -Wall to keep your code clean of smells. You might also look at Agda, Isabelle or Catch for more assurance. For lint-like checking, see the great hlint, which will suggest improvements.

With all these tools you can keep a handle on complexity, removing as many interactions between components as possible. Ideally, you have a very large base of pure code, which is really easy to maintain, since it is compositional. That's not always possible, but it is worth aiming for.

In general: decompose the logical units of your system into the smallest referentially transparent components possible, then implement them in modules. Global or local environments for sets of components (or inside components) might be mapped to monads. Use algebraic data types to describe core data structures. Share those definitions widely.

---

Don gave you most of the details above, but here's my two cents from doing really nitty-gritty stateful programs like system daemons in Haskell.

1. In the end, you live in a monad transformer stack. At the bottom is IO. Above that, every major module (in the abstract sense, not the module-in-a-file sense) maps its necessary state into a layer in that stack. So if you have your database connection code hidden in a module, you write it all to be over a type MonadReader Connection m => ... -> m ... and then your database functions can always get their connection without functions from other modules having to be aware of its existence. You might end up with one layer carrying your database connection, another your configuration, a third your various semaphores and mvars for the resolution of parallelism and synchronization, another your log file handles, etc.

2. Figure out your error handling first. The greatest weakness at the moment for Haskell in larger systems is the plethora of error handling methods, including lousy ones like Maybe (which is wrong because you can't return any information on what went wrong; always use Either instead of Maybe unless you really just mean missing values). Figure out how you're going to do it first, and set up adapters from the various error handling mechanisms your libraries and other code uses into your final one. This will save you a world of grief later.

Addendum (extracted from comments; thanks to Lii & liminalisht) —
more discussion about different ways to slice a large program into monads in a stack:

Ben Kolera gives a great practical intro to this topic, and Brian Hurt discusses solutions to the problem of lifting monadic actions into your custom monad. George Wilson shows how to use mtl to write code that works with any monad that implements the required typeclasses, rather than your custom monad kind. Carlo Hamalainen has written some short, useful notes summarizing George's talk.

---

Designing large programs in Haskell is not that different from doing it in other languages. Programming in the large is about breaking your problem into manageable pieces, and how to fit those together; the implementation language is less important.

That said, in a large design it's nice to try and leverage the type system to make sure you can only fit your pieces together in a way that is correct. This might involve newtype or phantom types to make things that appear to have the same type be different.

When it comes to refactoring the code as you go along, purity is a great boon, so try to keep as much of the code as possible pure. Pure code is easy to refactor, because it has no hidden interaction with other parts of your program.

---

I did learn structured functional programming the first time with this book. It may not be exactly what you are looking for, but for beginners in functional programming, this may be one of the best first steps to learn to structure functional programs - independant of the scale. On all abstraction levels, the design should always have clearly arranged structures.

The Craft of Functional Programming

http://www.cs.kent.ac.uk/people/staff/sjt/craft2e/

---

I'm currently writing a book with the title "Functional Design and Architecture". It provides you with a complete set of techniques how to build a big application using pure functional approach. It describes many functional patterns and ideas while building an SCADA-like application 'Andromeda' for controlling spaceships from scratch. My primary language is Haskell. The book covers:

• Approaches to architecture modelling using diagrams;
• Requirements analysis;
• Embedded DSL domain modelling;
• External DSL design and implementation;
• Monads as subsystems with effects;
• Free monads as functional interfaces;
• Arrowised eDSLs;
• Inversion of Control using Free monadic eDSLs;
• Software Transactional Memory;
• Lenses;
• State, Reader, Writer, RWS, ST monads;
• Impure state: IORef, MVar, STM;
• Multithreading and concurrent domain modelling;
• GUI;
• Applicability of mainstream techniques and approaches such as UML, SOLID, GRASP;
• Interaction with impure subsystems.

You may get familiar with the code for the book here, and the 'Andromeda' project code.

I expect to finish this book at the end of 2017. Until that happens, you may read my article "Design and Architecture in Functional Programming" (Rus) here.

UPDATE

I shared my book online (first 5 chapters). See post on Reddit

---

Gabriel's blog post Scalable program architectures might be worth a mention.

Haskell design patterns differ from mainstream design patterns in one important way:

• Conventional architecture: Combine a several components together of type A to generate a "network" or "topology" of type B

• Haskell architecture: Combine several components together of type A to generate a new component of the same type A, indistinguishable in character from its substituent parts

It often strikes me that an apparently elegant architecture often tends to fall out of libraries that exhibit this nice sense of homogeneity, in a bottom-up sort of way. In Haskell this is especially apparent - patterns that would traditionally be considered "top-down architecture" tend to be captured in libraries like mvc, Netwire and Cloud Haskell. That is to say, I hope this answer will not be interpreted as an attempt replace any of the others in this thread, just that structural choices can and should ideally be abstracted away in libraries by domain experts. The real difficulty in building large systems, in my opinion, is evaluating these libraries on their architectural "goodness" versus all of your pragmatic concerns.

As liminalisht mentions in the comments, The category design pattern is another post by Gabriel on the topic, in a similar vein.

---

I have found the paper "Teaching Software Architecture Using Haskell" (pdf) by Alejandro Serrano useful for thinking about large-scale structure in Haskell.

---

Perhaps you have to go an step back and think of how to translate the description of the problem to a design in the first place. Since Haskell is so high level, it can capture the description of the problem in the form of data structures , the actions as procedures and the pure transformation as functions. Then you have a design. The development start when you compile this code and find concrete errors about missing fields, missing instances and missing monadic transformers in your code, because for example you perform a database Access from a library that need a certain state monad within an IO procedure. And voila, there is the program. The compiler feed your mental sketches and gives coherence to the design and the development.

In such a way you benefit from the help of Haskell since the beginning, and the coding is natural. I would not care to do something "functional" or "pure" or enough general if what you have in mind is a concrete ordinary problem. I think that over-engineering is the most dangerous thing in IT. Things are different when the problem is to create a library that abstract a set of related problems.

참고URL : https://stackoverflow.com/questions/3077866/large-scale-design-in-haskell