리액티브 프로그래밍

Reactive programming
프로그래밍 패러다임

컴퓨팅에서 리액티브 프로그래밍은 데이터 스트림과 변화의 전파에 관한 선언적 프로그래밍 패러다임입니다.이 패러다임에서는 정적 데이터 스트림(예: 어레이) 또는 동적 데이터 스트림(예: 이벤트 방출기)을 쉽게 표현할 수 있으며, 또한 관련 실행 모델 내에 추정된 종속성이 존재함을 알릴 수 있으므로 변경된 데이터 [citation needed]흐름의 자동 전파가 용이해집니다.

예를 들어, 명령형 프로그래밍 설정에서는a := b + c라는 의미일 것이다a의 결과를 할당받고 있다b + c그 표현이 평가되는 순간, 그리고 나중에, 가치들b그리고.c가치에 영향을 주지 않고 변경할 수 있다a반면에 리액티브 프로그래밍에서는a값은 항상 자동으로 갱신됩니다.b또는c변경(프로그램이 명시적으로 스테이트먼트를 재작성할 필요가 없음)a := b + c현재 할당된 값을 결정하다a를 클릭합니다.[citation needed] 

변화하다 b = 1 변화하다 c = 2 변화하다 a = b + c b = 10 콘솔.로그.(a) // 3("="은 반응형 할당 연산자가 아니므로 12가 아님)  // 명시적으로 초기화된 경우뿐만 아니라 참조된 변수(연산자의 오른쪽)가 변경되었을 때 변수의 값을 변경하는 특수 연산자 "$="가 있다고 가정합니다. 변화하다 b = 1 변화하다 c = 2 변화하다 a $= b + c b = 10 콘솔.로그.(a) // 12

또 다른 예로는 Verilog와 같은 하드웨어 기술 언어를 들 수 있습니다.이 언어에서는 리액티브 프로그래밍을 통해 변경 내용이 [citation needed]회선을 통해 전파될 때 이를 모델링할 수 있습니다.

대화형 사용자 인터페이스와 실시간에 가까운 시스템 [citation needed]애니메이션의 생성을 단순화하는 방법으로 사후 프로그래밍이 제안되었습니다.

예를 들어 모델-뷰-컨트롤러(MVC) 아키텍처에서 사후 프로그래밍은 연관된 [1]뷰에 자동으로 반영되는 기본 모델의 변경을 촉진할 수 있습니다.

사후 대응형 프로그래밍 언어 작성 방법

반응형 프로그래밍 언어 작성에는 몇 가지 일반적인 접근법이 사용됩니다.다양한 도메인 제약에 고유한 전용 언어 지정.이러한 제약은 일반적으로 실시간 임베디드 컴퓨팅 또는 하드웨어 설명에 의해 특징지어집니다.또 다른 접근법은 반응성 지원을 포함하는 범용 언어의 지정과 관련이 있다.다른 접근법은 프로그래밍 언어와 함께 또는 프로그래밍 언어 위에 반응성을 가능하게 하는 프로그래밍 라이브러리 또는 임베디드 도메인 고유의 언어의 정의 및 사용에 명시되어 있습니다.이러한 다양한 접근방식을 지정 및 사용하면 언어 능력의 트레이드오프가 발생합니다.일반적으로 언어가 제한될수록 관련 컴파일러 및 분석 도구는 개발자에게 더 많은 정보를 제공할 수 있습니다(예를 들어 프로그램이 실시간으로 실행될 수 있는지 여부를 분석할 때).특정성에서의 기능적 균형은 언어의 일반적인 적용 가능성을 악화시킬 수 있다.

프로그래밍 모델 및 의미론

다양한 모델과 의미론이 반응형 프로그래밍 패밀리를 지배합니다.다음 치수에 따라 느슨하게 나눌 수 있습니다.

  • Synchrony: 시간의 기본 모델은 동기식입니까 비동기식입니까?
  • 결정론:평가 과정과 결과 모두에서 결정론적 대 비결정론적
  • 갱신 프로세스: 콜백과 데이터 흐름과 액터

구현 기술과 과제

구현의 본질

반응형 프로그래밍 언어 런타임은 관련된 반응형 값 간의 의존성을 식별하는 그래프로 나타납니다.이러한 그래프에서 노드는 컴퓨팅의 동작을 나타내며 에지 모델은 의존 관계를 나타냅니다.이러한 런타임은 해당 그래프를 사용하여 관련된 입력이 값을 변경하면 새로 실행되어야 하는 다양한 계산을 추적합니다.

전파 알고리즘 변경

데이터 전파에 대한 가장 일반적인 접근 방식은 다음과 같습니다.

  • Pull: 실제로 소비자는 사전 예방적이어서 정기적으로 관찰된 소스에 값을 쿼리하고 관련 값을 사용할 수 있을 때마다 반응합니다.이벤트나 값의 변경을 정기적으로 체크하는 이 관행을 일반적으로 폴링이라고 부릅니다.
  • Push: 값 컨슈머는 값을 사용할 수 있게 될 때마다 소스로부터 값을 받습니다.이 값들은 자급자족하며, 예를 들어 필요한 모든 정보를 포함하며, 소비자가 추가 정보를 조회할 필요가 없다.
  • 푸시풀:값 소비자는 변경에 대한 간단한 설명(예: "일부 값이 변경됨")인 변경 알림을 받습니다. 이것은 푸시 부분입니다.다만, 통지에 필요한 정보가 모두 포함되어 있는 것은 아니기 때문에(실제 값이 포함되어 있지 않은 것을 의미), 사용자는 통지가 수신된 후에 발신기지(특정 값)에 대해 문의할 필요가 있습니다.이것은 풀 파트입니다.이 방법은 소비자들이 잠재적으로 관심을 가질 수 있는 대량의 데이터가 있을 때 일반적으로 사용됩니다.따라서 throughput과 지연을 줄이기 위해 경량 알림만 전송됩니다.그 후 더 많은 정보를 필요로 하는 소비자는 특정 정보를 요구합니다.또, 이 어프로치에서는, 통지가 송신된 후에, 송신원에 많은 추가 정보의 요구가 쇄도하는 단점도 있습니다.

뭘 밀어요?

구현 수준에서 이벤트 반응은 그래프의 정보를 통한 전파로 구성되며, 변경의 존재를 특징짓습니다.따라서 이러한 변경의 영향을 받는 계산은 구식이므로 재실행을 위해 플래그를 붙여야 합니다.그러한 계산은 일반적으로 관련 출처의 변경에 대한 과도적 폐쇄로 특징지어진다.변경 전파로 인해 그래프 싱크 값이 업데이트될 수 있습니다.

그래프 전파 정보는 노드의 완전한 상태, 즉 관련된 노드의 계산 결과로 구성될 수 있습니다.이 경우 노드의 이전 출력은 무시됩니다.또 다른 방법은 델타 전파, 즉 증분 변화 전파를 포함한다.이 경우, 이전 노드가 어떻게 변경되었는지 설명하는 델타만으로 구성된 그래프의 가장자리를 따라 정보가 확산됩니다.이 접근방식은 노드가 대량의 상태 데이터를 보유하고 있을 때 특히 중요합니다.이러한 데이터는 처음부터 재계산하는 데 비용이 많이 듭니다.

델타 전파는 기본적으로 증분 컴퓨팅을 통해 광범위하게 연구되어 온 최적화로, 뷰 업데이트 문제를 포함한 런타임 만족도를 필요로 합니다.이 문제는 변경되는 데이터 뷰의 유지보수를 담당하는 데이터베이스 엔티티를 사용하는 것으로 악명높게 특징지어집니다.

또 다른 일반적인 최적화는 단항 변경 축적과 배치 전파를 사용하는 것입니다.이러한 솔루션은 관련된 노드 간의 통신을 줄이기 때문에 더 빠를 수 있습니다.그런 다음, 그 안에 포함된 변경의 특성에 대한 이유를 제시하고 그에 따라 변경을 가할 수 있다. 예를 들어, 배치의 두 가지 변경은 서로를 취소할 수 있으므로, 단순히 무시될 수 있다.또 다른 이용 가능한 접근법은 무효 알림 전파로 설명됩니다.이 방법을 사용하면 입력이 비활성화된 노드가 업데이트를 풀하여 자체 출력이 업데이트됩니다.

의존관계 그래프 작성에는 주로 두 가지 방법이 있습니다.

  1. 의존관계 그래프는 이벤트루프 내에서 암묵적으로 유지됩니다.명시적 콜백을 등록하면 암묵적인 의존관계가 생성됩니다.따라서 콜백을 통해 유도되는 제어 반전은 그대로 유지됩니다.그러나 콜백을 기능시키기 위해서는(즉, 단위값 대신 상태값을 반환하는) 그러한 콜백이 구성되어야 합니다.
  2. 의존관계 그래프는 프로그램 고유하며 프로그래머에 의해 생성됩니다.이것에 의해, 2개의 방법으로 콜백의 제어 반전의 어드레싱이 용이하게 됩니다.그래프는 명시적으로 지정되거나(일반적으로 짜넣을 수 있는 도메인 고유의 언어(DSL)를 사용하여), 그래프는 효과적인 원형 언어를 사용하여 표현과 생성으로 암묵적으로 정의됩니다.

사후 대응형 프로그래밍 구현 과제

결함

변경을 전파할 때 식 값이 소스 프로그램의 자연스러운 결과가 되지 않도록 전파 순서를 선택할 수 있습니다.예를 들면, 이것을 간단하게 설명할 수 있습니다.가정하다seconds는, 현재의 시각(초단위)을 나타내기 위해서 매초 변화하는 무효치입니다.다음 표현에 대해 생각해 봅시다.

t = 초 + 1 g = (t > 초)
Reactive programming glitches.svg

왜냐면t항상 보다 커야 한다seconds이 식은 항상 참값으로 평가해야 합니다.안타깝게도, 이것은 평가 순서에 따라 달라질 수 있습니다.언제seconds다음 두 가지 식을 갱신해야 합니다.seconds + 1그리고 조건입니다.첫 번째가 두 번째보다 먼저 평가되면 이 불변성이 유지됩니다.단, 조건부 갱신이 먼저 이루어진 경우 이전 값을 사용하여t그리고 새로운 가치seconds이 식은 false 값으로 평가됩니다.이를 글리치라고 합니다.

일부 반응형 언어는 글리치가 없으며 이 특성을[citation needed] 증명합니다.이 작업은 보통 위상식으로 식을 정렬하고 위상 순서로 값을 업데이트함으로써 수행됩니다.단, 이 경우 (전파 순서에 따라) 값 전달이 지연되는 등 퍼포먼스에 영향이 있을 수 있습니다.따라서 경우에 따라서는 리액티브한 언어에 의해 글리치가 허용되며 개발자는 값이 일시적으로 프로그램소스에 대응하지 못할 수 있으며 일부 표현식은 여러 번 평가될 수 있다는 점을 인지해야 합니다(예를 들어,t > seconds두 번 평가할 수 있습니다.한 번 평가하면 새로운 값이seconds도착해서 다시 한 번t갱신).

순환 의존 관계

의존관계 토폴로지 정렬은 directed ascyclic graph(DAG; 유도 비순환 그래프)인 의존관계 그래프에 따라 달라집니다.실제로 프로그램은 주기를 갖는 종속성 그래프를 정의할 수 있습니다.일반적으로 반응형 프로그래밍 언어에서는 반응형 업데이트가 종료될 수 있도록 일부 요소를 "백 에지"에 배치함으로써 이러한 사이클이 "중단"될 것으로 예상합니다.일반적으로 언어는 다음과 같은 연산자를 제공합니다.delay이 목적을 위해 갱신 메커니즘에 의해 사용됩니다.delay는, 다음의 내용을 「다음의 순서」에서 평가할 필요가 있는 것을 의미합니다(현재 평가가 종료되도록 합니다).

가변 상태와의 상호 작용

반응형 언어에서는 일반적으로 표현식이 순수하게 기능한다고 가정합니다.이를 통해 업데이트 메커니즘은 업데이트를 수행할 다른 순서를 선택하고 특정 순서를 지정하지 않은 상태로 둘 수 있습니다(따라서 최적화를 활성화).그러나 상태가 있는 프로그래밍 언어에 반응형 언어가 포함되어 있는 경우 프로그래머가 가변 연산을 수행할 수 있습니다.이 상호작용을 원활하게 하는 방법은 여전히 미해결 문제로 남아 있습니다.

경우에 따라서는 원칙적인 부분 해법이 있을 수 있습니다.이러한 솔루션에는 다음 두 가지가 있습니다.

  • 언어는 "변환 셀"의 개념을 제공할 수 있습니다.가변 셀은 리액티브 업데이트 시스템이 인식하고 있는 셀이며, 셀에 대한 변경이 리액티브 프로그램의 나머지 부분에 전파됩니다.이것에 의해, 프로그램의 비반응 부분이 기존의 변환을 실행하면서, 반응하는 코드가 이 업데이트를 인식하고 응답할 수 있게 되어, 프로그램내의 값간의 관계의 일관성을 유지할 수 있게 됩니다.이러한 셀을 제공하는 반응형 언어의 예로는 FrTime이 [2]있습니다.
  • 적절하게 캡슐화된 객체 지향 라이브러리는 캡슐화된 상태의 개념을 제공합니다.따라서 원칙적으로 이러한 라이브러리는 언어의 반응적인 부분과 원활하게 상호작용할 수 있습니다.예를 들어 콜백을 오브젝트 지향 라이브러리의 getter에 설치하여 리액티브 업데이트엔진에 상태 변경을 통지하고 리액티브컴포넌트의 변경을 getter를 통해 오브젝트 지향 라이브러리에 푸시할 수 있습니다.Fr Time은 이러한 전략을 [3]채택하고 있습니다.

종속성 그래프의 동적 업데이트

일부 반응형 언어에서 종속성의 그래프는 정적입니다. 즉, 그래프는 프로그램 실행 내내 고정됩니다.다른 언어에서는 그래프가 동적일 수 있습니다. 즉, 프로그램이 실행됨에 따라 그래프가 변경될 수 있습니다.간단한 예로서 이 예시를 검토해 주십시오(여기서).seconds무효값) : 

t = if (seconds mod 2) == 0): 초 + 1 기타: 초 - 1 끝 t + 1

매초 이 식의 값은 다른 반응식으로 바뀝니다.t + 1상황에 따라 다르죠따라서 종속성 그래프는 매초 업데이트됩니다.

의존관계를 동적으로 갱신할 수 있게 되면 상당한 표현력을 얻을 수 있습니다(예를 들어 동적 의존관계는 그래픽 사용자 인터페이스(GUI) 프로그램에서 일상적으로 발생합니다).단, 리액티브업데이트 엔진은 식을 매번 재구성할지 또는 식의 노드를 생성하지만 비활성 상태로 둘지 결정해야 합니다.후자의 경우 활성화되지 않아야 할 경우에는 계산에 참여하지 않도록 해야 합니다.

개념

명시도

반응형 프로그래밍 언어는 화살표를 사용하여 데이터 흐름을 설정하는 매우 명시적인 언어에서 필수 또는 기능적 프로그래밍과 유사한 언어 구조에서 데이터 흐름이 파생되는 암묵적인 언어까지 다양합니다.예를 들어 암묵적으로 리프팅된 Functional Reactive Programming(FRP)에서는 함수 호출이 암묵적으로 데이터 흐름 그래프 내의 노드를 구성할 수 있습니다.동적 언어를 위한 리액티브 프로그래밍 라이브러리(예: Lisp "Cells" 및 Python "Trelis" 라이브러리)는 함수의 실행 중에 읽혀진 값의 런타임 분석으로부터 의존관계 그래프를 구성할 수 있으며, 데이터 흐름 사양을 암묵적이고 역동적으로 만들 수 있습니다.

때로는 사후 프로그래밍이라는 용어는 소프트웨어 엔지니어링의 아키텍처 수준을 가리킵니다.여기서 데이터 흐름 그래프의 개별 노드는 서로 통신하는 일반적인 프로그램입니다.

정적 또는 동적

반응형 프로그래밍은 데이터 흐름이 정적으로 설정되는 순수 정적 프로그래밍이거나 프로그램 실행 중에 데이터 흐름이 변경될 수 있는 동적 프로그래밍일 수 있습니다.

데이터 흐름 그래프에서 데이터 스위치를 사용하면 정적 데이터 흐름 그래프가 어느 정도 동적인 것처럼 보여 구분이 약간 흐려질 수 있습니다.그러나 진정한 동적 반응형 프로그래밍은 필수 프로그래밍을 사용하여 데이터 흐름 그래프를 재구성할 수 있습니다.

고차 반응형 프로그래밍

데이터 플로우를 사용하여 다른 데이터 플로우를 구성할 수 있는 개념을 지원하는 경우 사후 프로그래밍이 더 높은 차수라고 할 수 있습니다.즉, 데이터 흐름의 결과 값은 첫 번째와 동일한 평가 모델을 사용하여 실행되는 또 다른 데이터 흐름 그래프입니다.

데이터 흐름의 차별화

모든 데이터 변경이 즉시 전파되는 것이 이상적이지만, 실제로는 이를 보장할 수 없습니다.대신 데이터 흐름 그래프의 다른 부분에 다른 평가 우선순위를 부여할 필요가 있을 수 있습니다.이를 차등 대응 [4]프로그래밍이라고 할 수 있습니다.

예를 들어 워드프로세서에서는 철자 오류 마킹이 문자 삽입과 완전히 일치할 필요는 없습니다.여기서 차별화된 반응형 프로그래밍은 잠재적으로 철자 검사기에 낮은 우선순위를 부여하기 위해 사용될 수 있으며, 다른 데이터 흐름은 즉시 유지하면서도 지연될 수 있습니다.

그러나 이러한 차별화로 인해 설계 복잡성이 가중됩니다.예를 들어, 다양한 데이터 흐름 영역을 정의하는 방법 및 서로 다른 데이터 흐름 영역 간에 전달되는 이벤트를 처리하는 방법을 결정합니다.

사후 프로그래밍 평가 모델

반응형 프로그램의 평가는 반드시 스택 기반 프로그래밍 언어의 평가 방법에 기초할 필요는 없습니다.대신 일부 데이터가 변경되면 변경 내용은 변경된 데이터에서 부분적으로 또는 완전히 파생된 모든 데이터에 전파됩니다.이 변경 전파는 여러 가지 방법으로 이루어질 수 있으며, 아마도 가장 자연스러운 방법은 무효화/불필요한 재검증 방식일 것입니다.

데이터 구조가 특정 형태를 가질 경우 지수 업데이트가 복잡해질 수 있기 때문에 단순히 스택을 사용하여 변경을 전파하는 것은 문제가 될 수 있습니다.이러한 형상 중 하나는 "반복 다이아몬드 형상"으로 설명할 수 있으며 다음과 같은 구조를 가지고 있다.An→Bn→An+1, An→Cn→An+1, 여기서 n=1,2...이 문제는 일부 데이터가 아직 비활성화되지 않은 경우에만 비활성화를 전파하고 나중에 느린 평가를 사용하여 필요할 때 데이터를 다시 검증함으로써 해결할 수 있습니다.

리액티브 프로그래밍의 본질적인 문제 중 하나는 일반적인 프로그래밍 언어로 평가되고 잊혀지는 대부분의 계산은 데이터 [citation needed]구조로서 메모리에 표시되어야 한다는 것입니다.이로 인해 리액티브프로그래밍이 메모리를 많이 소비하게 될 가능성이 있습니다.하지만, 하향이라고 불리는 것에 대한 연구는 잠재적으로 이 [5]문제를 극복할 수 있다.

한편, 리액티브 프로그래밍은 '명시적 병렬화'[citation needed]라고 할 수 있는 형태이므로 병렬 하드웨어의 성능을 활용하는 데 도움이 될 수 있습니다.

관찰자 패턴과의 유사성

리액티브 프로그래밍은 객체 지향 프로그래밍에서 일반적으로 사용되는 옵저버 패턴과 주요 유사성을 가지고 있습니다.그러나 데이터 흐름 개념을 프로그래밍 언어로 통합하면 표현하기가 더 쉬워지므로 데이터 흐름 그래프의 세분성을 높일 수 있습니다.예를 들어, 관찰자 패턴은 일반적으로 전체 개체/클래스 간의 데이터 흐름을 설명하는 반면, 개체 지향 반응형 프로그래밍은 개체/클래스의 구성원을 대상으로 할 수 있습니다.

접근

필수

반응형 프로그래밍과 일반 필수 프로그래밍을 융합할 수 있습니다.이러한 패러다임에서 필수 프로그램은 반응형 데이터 구조에 [6]따라 작동합니다.이러한 설정은 제약조건 명령형 프로그래밍과 유사하지만 제약조건 명령형 프로그래밍이 양방향 제약조건을 관리하는 반면 반응형 명령형 프로그래밍은 단방향 데이터 흐름 제약조건을 관리합니다.

객체 지향

객체 지향 반응형 프로그래밍(OORP)은 객체 지향 프로그래밍과 반응형 프로그래밍의 조합입니다.이러한 조합을 만드는 가장 자연스러운 방법은 다음과 같습니다.메서드나 필드 대신 오브젝트에는 자신이 의존하는 다른 반응이 [citation needed]수정되었을 때 자동으로 재평가되는 반응이 있습니다.

OORP 언어가 명령형 메서드를 유지하는 경우 명령형 반응형 프로그래밍의 범주에 속합니다.

기능하다

FRP(Functional Reactive Programming)는 기능 프로그래밍에 대한 리액티브 프로그래밍의 프로그래밍 패러다임입니다.

배우 기반

행위자들은 사후 대응 시스템을 설계할 것을 제안받았으며,[7][8] 종종 분산 사후 대응 시스템을 개발하기 위해 기능 사후 대응 프로그래밍(FRP)과 결합한다.

규칙 기반

비교적 새로운 범주의 프로그래밍 언어에서는 제약(규칙)을 주요 프로그래밍 개념으로 사용합니다.이벤트에 대한 반응으로 구성되어 모든 제약 조건을 충족합니다.이는 이벤트 기반 반응을 촉진할 뿐만 아니라 사후 대응적인 프로그램을 소프트웨어의 정확성에 중요한 요소로 만듭니다.규칙 기반의 리액티브 프로그래밍 언어의 예로는 관계대수에서 확립된 앰퍼샌드가 있습니다.[9]

실장

  • ReactiveX는 RxJs, RxJava 등의 다국어 구현으로 스트림, 관측 가능 및 연산자를 사용한 사후 대응 프로그래밍을 구현하기 위한 API입니다.NET, RxPy 및 RxSwift.
  • Elm(프로그래밍 언어) 웹 사용자 인터페이스의 반응적 구성.
  • Reactive Streams, 비블로킹 배압 비동기 스트림 처리를 위한 JVM 표준
  • 관찰 가능한 컴퓨팅, 크로스 플랫폼.NET의 실장.
  • Svelte는 JavaScript와 비슷하지만 JavaScript가 보통 그렇지 않은 경우에는 자연스럽게 반응하는 변형 JavaScript 구문의 형태로 반응성을 가져옵니다.
  • Solid.js는 JavaScript 구문 시멘틱스를 변경하지 않고 JavaScript에 반응성을 제공합니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ 를 클릭합니다Trellis, Model-view-controller and the observer pattern, Tele community.
  2. ^ "Embedding Dynamic Dataflow in a Call-by-Value Language". cs.brown.edu. Retrieved 2016-10-09.
  3. ^ "Crossing State Lines: Adapting Object-Oriented Frameworks to Functional Reactive Languages". cs.brown.edu. Retrieved 2016-10-09.
  4. ^ "Reactive Programming – The Art of Service The IT Management Guide". theartofservice.com. Retrieved 2016-07-02.
  5. ^ 를 클릭합니다Burchett, Kimberley; Cooper, Gregory H; Krishnamurthi, Shriram, "Lowering: a static optimization technique for transparent functional reactivity", Proceedings of the 2007 ACM SIGPLAN symposium on Partial evaluation and semantics-based program manipulation (PDF), pp. 71–80.
  6. ^ 를 클릭합니다Demetrescu, Camil; Finocchi, Irene; Ribichini, Andrea (22 October 2011), "Reactive Imperative Programming with Dataflow Constraints", Proceedings of the 2011 ACM international conference on Object oriented programming systems languages and applications, Oopsla '11, pp. 407–26, doi:10.1145/2048066.2048100, ISBN 9781450309400, S2CID 7285961.
  7. ^ 를 클릭합니다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.
  8. ^ 를 클릭합니다Shibanai, Kazuhiro; Watanabe, Takuo (2018), "Distributed Functional Reactive Programming on Actor-Based Runtime", Proceedings of the 8th ACM SIGPLAN International Workshop on Programming Based on Actors, Agents, and Decentralized Control, Agere 2018, pp. 13–22, doi:10.1145/3281366.3281370, ISBN 9781450360661, S2CID 53113447.
  9. ^ 를 클릭합니다Joosten, Stef (2018), "Relation Algebra as programming language using the Ampersand compiler", Journal of Logical and Algebraic Methods in Programming, vol. 100, pp. 113–29, doi:10.1016/j.jlamp.2018.04.002, S2CID 52932824.

외부 링크