Idris2+WebGL, 파트 #7: 짧은 코드 품질 업데이트

이전 개발 로그를 작성하는 동안 GL 모나드로 전환하면 연속 작업 없이 선형 유형을 사용할 수 있다는 것을 깨달았습니다. 실제로 그렇습니다.

Idris는 음수 위치의 유형, 즉 입력에서 선형성을 결정합니다. f x 표현식은 f 또는 x가 선형이면 선형이고, 따라서 f x y f 또는 x가 선형이면 표현식 y도 선형입니다. 그러나 GADT를 사용하면 가능합니다. 생성자 함수에서 선형성을 지정하십시오. 이는 정확히 제가 GL 모나드에서 수행한 작업입니다. 이를 통해 "일반"반환 값을 위해 대부분의 연속 작업을 제거할 수 있었습니다.

나는 또한 인터페이스와 MTL과 같은 기능으로 나아가고 있지만 종속 유형 프로그래밍에 대한 경험을 조금 더 쌓을 때까지 커밋하지 않을 것입니다.
지금은 HasGL 및 HasAllocator 둘 다 구현하지만 실제 모나드 변환기는 아직 구현하지 않은 모나드Graphics와 인터페이스했습니다.

이러한 변경 사항의 조합으로 코드를 훨씬 더 읽기 쉽게 만들 수 있습니다. 에서:

makeTriangle : (1 _ : (1 _ : Drawable) -> GL a) -> GL a
makeTriangle p =
  createShaderProgram vertexShaderSource fragmentShaderSource $ \program =>
    createBuffer $ \buffer =>
      float32Array [ -1,-1, 1, -1, 0, 1 ] $ \triangleData => do
          positionAttribLocation @@ program <- getAttribLocation program "aPosition"
          scaleUniformLocation @@ program <- getUniformLocation program "xScale"
          buffer <- bindBuffer GL_ARRAY_BUFFER buffer
          triangleData <- bufferData GL_ARRAY_BUFFER triangleData GL_STATIC_DRAW
          () <- deleteArray triangleData
          p $ MkDrawable program buffer positionAttribLocation scaleUniformLocation

내가 지금 가지고 있는 것:

makeTriangle : Graphics Drawable
makeTriangle = do
  triangleData                      <- float32Array [ -1,-1, 1, -1, 0, 1 ]
  program                           <- createShaderProgram vertexShaderSource fragmentShaderSource
  buffer                            <- createBuffer
  positionAttribLocation @@ program <- getAttribLocation program "aPosition"
  scaleUniformLocation @@ program   <- getUniformLocation program "xScale"
  buffer                            <- bindBuffer GL_ARRAY_BUFFER buffer
  triangleData                      <- bufferData GL_ARRAY_BUFFER triangleData GL_STATIC_DRAW
  ()                                <- deleteArray triangleData
  pure $ MkDrawable program buffer positionAttribLocation scaleUniformLocation

이제 이것이 절차적 프로그래밍에 매우 가깝다고 말할 수 있습니다. 그렇다면 C가 아닌 Idris를 사용하는 이유는 무엇입니까? 우리가 본질적으로 절차적 프로그래밍을 하고 있는 것은 사실이지만, 우리는 형식 안전성 측면에서 많은 것을 얻었습니다. WebGL/OpenGL 사양은 특별히 절차적 프로그래밍을 위해 작성되었으므로 이것은 불가피했습니다. 실제 그래픽 엔진을 구축할 때 더 전통적으로 기능적인 코드 스타일로 돌아가기 위해 The Elm Architecture와 유사한 것을 만들 수 있습니다. 드라이버 제어와 같은 저수준 작업의 경우 절차 스타일 및 많은 선형 유형이 나에게 올바른 방법인 것 같습니다.