기능적 사후 대응 프로그래밍

Functional reactive programming
일부 안드로이드 장치의 기능인 공장 초기화 방지(FRP)와 혼동하지 마십시오.
프로그래밍 패러다임

FRP(Functional Reactive Programming)는 기능 프로그래밍의 구성 요소(예: 지도, 축소, 필터)를 사용한 사후 프로그래밍(비동기 데이터 흐름 프로그래밍)의 프로그래밍 패러다임입니다.FRP는 [citation needed]Graphical User Interface(GUI; 그래피컬사용자 인터페이스), 로보틱스, 게임 및 음악 프로그래밍에 사용되어 시간을 명시적으로 모델링함으로써 이러한 문제를 단순화하는 것을 목표로 하고 있습니다.

FRP의 제식

기능 반응 프로그래밍의 원래 공식은 코날 엘리엇과 Paul [1]Hudak의 ICFP 97 논문 Functional Reactive Animation에서 확인할 수 있습니다.

FRP는 1997년 도입된 이후 많은 형태를 취해왔다.다양성의 한 축은 이산적 의미론 대 연속적 의미론이다.또 하나의 축은 FRP 시스템을 [2]동적으로 변경하는 방법입니다.

계속되는

FRP의 초기 공식은 프로그램의 [3]의미에 중요하지 않은 많은 운영 세부 사항들을 추상화하는 것을 목표로 연속적인 의미론을 사용했다.이 공식의 주요 속성은 다음과 같습니다.

  • 연속된 시간에 따라 변화하는 값을 모델링합니다. 이를 "동작" 및 이후 "신호"라고 합니다.
  • 개별 시점에 발생하는 "사건" 모델링.
  • 시스템은 일반적으로 "스위칭"이라고 불리는 이벤트에 따라 변경될 수 있습니다.
  • 반응 모델에서 샘플링 속도 등의 평가 세부사항 분리

부작용 없는 언어에서 FRP의 의미 모델은 일반적으로 연속 함수의 관점에서 그리고 일반적으로 시간이 [4]지남에 따라 발생한다.

디스크리트

Event-Driven FRP나 0.17보다 이전 버전의 Elm과 같은 공식에서는 업데이트가 개별적이고 이벤트 [5]중심이어야 합니다.이러한 공식들은 로보틱스나 [6]웹 브라우저와 같은 설정에서 효율적으로 구현될 수 있는 단순한 API를 가진 의미론에 초점을 맞추어 실용적인 FRP를 추진해왔다.

이러한 공식에서 행동과 사건에 대한 아이디어는 항상 현재 값을 가지지만 [7]이산적으로 변화하는 신호로 결합되는 것이 일반적입니다.

인터랙티브 FRP

입력에서 출력에 이르기까지 일반적인 FRP 모델은 [8]인터랙티브 프로그램에 적합하지 않다는 지적이 제기되어 왔다.입력에서 출력까지의 매핑 내에서 프로그램을 "실행"할 수 없다는 것은 다음 중 하나의 솔루션을 사용해야 한다는 것을 의미합니다.

  • 출력으로 표시되는 작업의 데이터 구조를 만듭니다.액션은 외부 인터프리터 또는 환경에서 실행해야 합니다.이는 Haskell의 [9]원래 스트림 I/O 시스템의 모든 어려움을 그대로 이어받습니다.
  • Arrowized FRP를 사용하여 액션을 수행할 수 있는 화살표를 포함합니다.작업에는 ID가 있을 수도 있으며, 이를 통해 별도의 가변 저장소를 유지할 수 있습니다.이것은 Fudgets[10] 라이브러리와 더 일반적으로 Monadic Stream [11]Functions에서 채택된 접근법입니다.
  • 새로운 접근법은 (IO 모나드에서) 작업을 지금 실행할 수 있도록 허용하고 결과를 나중에 [12]받는 것입니다.이를 통해 이벤트와 IO 모나드 간의 상호작용이 사용되며 보다 표현 지향적인 FRP와 호환됩니다.
 지금 당장 계획하다 :: 이벤트 (입출력 a) -> 입출력 (이벤트 a)

구현 문제

FRP 시스템에는 푸시 베이스와 풀 베이스의 2종류가 있습니다.푸시 기반 시스템은 이벤트를 수신하여 신호 네트워크를 통해 푸시하여 결과를 얻습니다.풀 기반 시스템은 결과가 요구될 때까지 기다렸다가 네트워크를 통해 역방향으로 작동하여 요구된 값을 가져옵니다.

Yampa와 같은 일부 FRP 시스템에서는 샘플이 신호 네트워크에 의해 풀리는 샘플링을 사용합니다.이 방법에는 단점이 있습니다.네트워크는 입력의 변경을 확인하기 위해1회의 계산 스텝까지 대기해야 합니다.샘플링은 풀베이스 FRP의 예입니다.

Hackage의 Reactive 및 Etage 라이브러리는 푸시풀 FRP라고 하는 접근방식을 도입했습니다.이 접근법에서는 완전히 정의된 스트림의 다음 이벤트(시간이 있는 고정 이벤트 목록 등)가 요구될 때만 해당 이벤트가 구성됩니다.이러한 순수하게 정의된 스트림은 Haskell의 게으른 목록처럼 작동합니다.저것이 풀 베이스의 반쪽입니다.푸시 기반 절반은 시스템 외부 이벤트를 가져올 때 사용됩니다.외부 이벤트는 소비자에게 푸시되므로 소비자는 이벤트가 발행되는 즉시 이벤트를 알 수 있습니다.

실장

  • Yampa는 SDL, SDL2, OpenGL 및 HTML DOM을 지원하는 화살표 형식의 효율적인 순수 Haskell 구현입니다.
  • Elm이 FRP를 지원하기 위해 사용한 프로그래밍 언어는 이후 다른 패턴으로 대체되었습니다.
  • 리플렉스는 Haskell에서 브라우저/DOM, SDL 및 Gloss용 호스트를 사용한 효율적인 푸시/풀 FRP 구현입니다.
  • reactive-banana는 Haskell에서 타겟에 구애받지 않는 푸시 FRP 구현입니다.
  • netwire 및 various는 화살표로 표시되어 있습니다.Haskell에서 풀 FRP를 구현합니다.
  • 플랩잭스는 JavaScript 동작/이벤트 FRP 구현입니다.
  • 리액트는 기능적 리액티브 프로그래밍을 위한 OCaml 모듈입니다.
  • Sodium은 Java, TypeScript 및 C#과 같은 여러 프로그래밍 언어에 대한 특정 UI 프레임워크와는 독립적인 푸시 FRP 구현입니다.
  • Dunai는 Monadic Stream Functions를 사용하여 Haskell에서 Classic 및 Arrowized FRP를 지원하는 고속 구현입니다.
  • 관찰 가능한 컴퓨팅, 크로스 플랫폼.NET의 실장.
  • Stella는 액터 기반 리액터 프로그래밍 언어이며, 액터 및 리액터 모델을 보여주고 있습니다.이것은 명령 코드와 리액터 코드를 조합하는 문제를 회피하는 것을 목적으로 하고 있습니다(액터 및 [15]리액터로 분리).작용기는 분산 반응 시스템에서 사용하기에 적합하다.
  • TindCycles는 순수 FRP 도메인 고유의 음악 패턴 언어로 Haskell 프로그래밍 언어에 포함되어 있습니다.

JavaScript 구현 rxjs에 의해 널리 보급된 ReactiveX는 기능과 반응성이 뛰어나지만 기능적인 반응형 [16]프로그래밍과는 다릅니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ Elliott, Conal; Hudak, Paul. "Functional Reactive Animation". Functional Reactive Animation. ICFP ’97. Retrieved 14 July 2018.
  2. ^ 를 클릭합니다Nilsson, Henrik; Courtney, Antony; Peterson, John (Feb 2011) [2002], "Functional Reactive Programming, Continued", Haskell Workshop (PDF).
  3. ^ 를 클릭합니다Elliott, Conal; Hudak, Paul (1997), "Functional Reactive Animation", ICFP.
  4. ^ 를 클릭합니다Courtney, Antony; Elliott, Conal (Feb 2011) [2001], "Genuinely Functional User Interfaces", Haskell Workshop, Yale.
  5. ^ 를 클릭합니다Taha, Walid; Wan, Zhanyong; Hudak, Paul (2002), "Event-Driven FRP", PADL (PDF), Yale, archived from the original (PDF) on 2013-09-28, retrieved 2013-09-23.
  6. ^ 를 클릭합니다Czaplicki, Evan; Chong, Stephen (2013), "Asynchronous Functional Reactive Programming for GUIs", PLDI, Harvard.
  7. ^ 를 클릭합니다Wan, Zhanyong; Taha, Walid; Hudak, Paul (Feb 2011), "Real-Time FRP", ICFP (PDF), archived from the original (PDF) on 2013-09-28, retrieved 2013-09-23.
  8. ^ "Conal Elliott » Why classic FRP does not fit interactive behavior".
  9. ^ https://courses.cs.washington.edu/courses/cse505/01au/functional/functional-io.pdf[베어 URL PDF]
  10. ^ "The Fudgets Thesis on WWW".
  11. ^ 를 클릭합니다Perez, Ivan; Barenz, Manuel; Nilsson, Henrik (July 2016), "Functional Reactive Programming, Refactored", Haskell Symposium (PDF).
  12. ^ "Archived copy" (PDF). Archived from the original (PDF) on 2015-07-01. Retrieved 2015-07-24.{{cite web}}: CS1 maint: 제목으로 아카이브된 복사(링크)
  13. ^ 를 클릭합니다Czaplicki, Evan (Apr 2012), Elm: Concurrent FRP for Functional GUIs (PDF) (thesis), Harvard, archived from the original (PDF) on 2016-06-04, retrieved 2015-02-17.
  14. ^ Czaplicki, Evan. "A Farewell to FRP". elm. Retrieved 14 July 2018.
  15. ^ 를 클릭합니다Van den Vonder, Sam; Renaux, Thierry; Oeyen, Bjarno; De Koster, Joeri; De Meuter, Wolfgang (2020), "Tackling the Awkward Squad for Reactive Programming: The Actor-Reactor Model", Leibniz International Proceedings in Informatics (LIPIcs), vol. 166, pp. 19:1–19:29, doi:10.4230/LIPIcs.ECOOP.2020.19, ISBN 9783959771542.
  16. ^ https://reactivex.io/intro.html 를 참조해 주세요.ReactiveX.io 를 참조해 주세요.2022년 7월 3일 취득.