リアクティブプログラミング

ϦΞΫςΟϒ ϓϩάϥϛϯά ৘ใ௨৴ݚڀػߏ ߴ໺༞ً

ݩωλ ➤ &OHJOFFS#BJOPNVHJTIB FUBM ʠ"4VSWFZPO3FBDUJWF1SPHSBNNJOHʡ +PVSOBMPG"$.$PNQVUJOH4VSWFZT 7PMVNF*TTVF "VHVTU
"SUJDMF/P 2

ϦΞΫςΟϒϓϩάϥϛϯά ➤ ΠϕϯτΛѻ͏ͨΊͷϓϩάϥϛϯάϞσϧ ➤ 'SBOʢݪ఺ʣ ➤ )BTLFMMͷϥΠϒϥϦͱͯ͠ఏڙ ➤ %΍%ͷΠϯλϥΫςΟϒͳΞχϝʔγϣϯΛѻ͏ͨΊʹੜ·Εͨ ➤
ΠϕϯτͷϞσϧԽ ➤ &--*055 $"/%)6%", 1 ʠ'VODUJPOBMSFBDUJWFBOJNBUJPOʡ *$'1 1SPDFFEJOHTPGUIFTFDPOE"$.4*(1-"/JOUFSOBUJPOBMDPOGFSFODFPO 'VODUJPOBMQSPHSBNNJOH 3

ίʔϧόοΫϕʔεͳϓϩάϥϛϯάͷ໰୊఺ ➤ ଟ͘ͷಠཱͨ͠ίʔυย͕ಉ͡σʔλΛૢ࡞͢Δ ➤ ࣮ߦॱ͕༧ଌෆՄೳ ➤ ίʔϧόοΫؔ਺͸ฦΓ஋Λ࣋ͨͳ͍ͨΊɺΞϓϦέʔγϣϯͷঢ়ଶʹ෭࡞༻Λٴ΅͢ඞཁ͕͋ Δʢάϩʔόϧม਺ʣ ➤ ͋Δ"EPCFͷσεΫτοϓΞϓϦͰ͸ɺόάͷ൒෼͕ɺΠϕϯτૢ࡞ͷϩδοΫ෦෼ͱؔ࿈
ʢ+ÅSWJ +FUBM ʠ1SPQFSUZNPEFMTGSPNJODJEFOUBMBMHPSJUINTUPSFVTBCMF DPNQPOFOUTʡ "$.(1$&ʣ ➤ ͦͷଞࢿྉ ➤ &EXBSET + ʠ$PIFSFOUSFBDUJPOʡ "$.4*(1-"/ ➤ ."*&3 * 30.1' 5 "/%0%&34,: . ʠ%FQSFDBUJOHUIF0CTFSWFS1BUUFSOʡ 5FDISFQPSU 4

࠷ۙͷྲྀΕ ➤ ϦΞΫςΟϒϓϩάϥϛϯάΛར༻ͨ͠ϥΠϒϥϦ͕ొ৔͖ͯͨ͠ ➤ 'BDFCPPLͷ3FBDUKT ➤ /&5ͷ/&539 ➤ 3Y+4 ➤
'SBQKBY ➤ 3Y4XJGU 5

ϦΞΫςΟϒ ϓϩάϥϛϯάͱ ͦͷಛ௃

ϦΞΫςΟϒϓϩάϥϛϯάʹ͓͚Δந৅Խ ➤ #FIBWJPST ➤ ࣌ؒతʹมԽ͢Δ஋ ➤ ࣌ؒܦաʹ൐͍࿈ଓతʹมԽ͢Δ ➤ &WFOUT ➤
࣌ؒॱʹฒͿ཭ࢄతͳ஋ 7 t event stream x event stream y behavior z = x + y 1 5 6 3 2 5 4 6 11 9 5 8 9 ΤΫηϧతͳϞσϧ

#FIBWJPSTͷධՁઓུ ➤ ஗ԆධՁ ➤ )BTLFMMͷϦΞΫςΟϒϓϩάϥϛϯάʢ'SBOɺ:BNQBʣͳͲ ➤ ඞཁʹͳͬͨ࣌ʹܭࢉ͕ߦΘΕΔͷͰແବ͕ͳ͍ ➤ ਖ਼֨ධՁ ➤
ਖ਼֨ධՁ͢Δݴޠ΋ଟ͍ ➤ ແବͳܭࢉΛলͨ͘ΊαϯϓϦϯά͞ΕΔ৔߹΋͋Δ 8

#FIBWJPSTͷධՁϞσϧɺQVMMͱQVTIʢ̍ʣ ➤ QVMMϕʔε ➤ ར఺ ➤ ඞཁͱͳΔ࣌ͷΈܭࢉ͢Ε͹ྑ͍ ➤ 'SBOɺ:BNQBͰ͸)BTLFMMͷ஗ԆධՁΛར༻ ➤
ܽ఺ ➤ Πϕϯτͷ഑ૹ஗Ԇ ➤ QVTIϕʔεͷ࣮૷ ➤ 'SBOɺ/FX'SBOɺ:BNQB ➤ ࠷ۙͷ/FX'SBO΍:BNQBͰ͸ɺ஗Ԇʹؔ͢Δ໰୊͸ղܾࡁΈΒ͍͠ 9 A Survey on Reactive Programming Producer Consumer Push data to the consumer Pull data from the producer The ﬂow of data Pull-based Push-based Fig. 2. Push- Versus Pull-based evaluation model 3.2. Evaluation Model The evaluation model of a reactive programming language is conc

#FIBWJPSTͷධՁϞσϧɺQVMMͱQVTIʢ̎ʣ ➤ QVTIϕʔε ➤ ར఺ ➤ Πϕϯτͷ഑ૹ஗Ԇ͸ͳ͍ ➤ ܽ఺ ➤
ແବͳ࠶ܭࢉΛߦ͏Մೳੑ͋Γ ➤ ྫ͑͹ɺ(6*ͷ΢Οϯυ΢͕όοΫάϥ΢ϯυͰ͋Δͱ͖͸ɺ(6*ʹؔ͢Δܭࢉ Λ͢Δඞཁ͸ͳ͍ɻQVTIϕʔεͩͱඞͣܭࢉ͢Δɻ ➤ QVTIϕʔεͷ࣮૷ ➤ 'MBQKBYɺ4DBMB3FBDUɺ'S5JNF 10 A Survey on Reactive Programming Producer Consumer Push data to the consumer Pull data from the producer The ﬂow of data Pull-based Push-based Fig. 2. Push- Versus Pull-based evaluation model 3.2. Evaluation Model The evaluation model of a reactive programming language is conce changes are propagated across a dependency graph of values and com the programmer’s point of view, propagation of changes happens autom this is the essence of reactive programming. A change of a value shou cally propagated to all dependent computations. When there is an eve an event source, dependent computations need to be notiﬁed about the bly triggering a recomputation. At the language level, the design dec to be taken into account is who initiates the propagation of changes. T

#FIBWJPSTͷධՁϞσϧɺQVMMͱQVTIʢ̏ʣ ➤ QVMMWTQVTI ➤ QVMMͷ৔߹ɺCFIBWJPSTͷॳظ஋Λܾఆ͠ͳͯ͘ྑ͍ͷ΋ར఺ ➤ QVTIͩͱॳظ஋͕ඞཁ ➤ ʢ͔͠͠ɺॳظ஋Λܾఆ͠ͳ͍ͱΠϕϯτͷೖྗ଴͕ͪൃੜ͢ΔͷͰɺҰ֓ʹ ར఺ͱ΋ݴ͑ͳ͍ͱࢥ͏ʣ
➤ QVTIͩͱάϦον͕ൃੜʂʢޙड़ʣ ➤ ྆ํ࢖͏࣮૷΋͋Δ ➤ -VMB4ZTUFN 'SBO 11 A Survey on Reactive Programming Producer Consumer Push data to the consumer Pull data from the producer The ﬂow of data Pull-based Push-based

άϦονͱͦͷରࡦʢ̍ʣ ➤ άϦονͱ͸ ➤ ύϧεతʹى͖ΔిؾతϊΠζ ➤ ઀৮ෆྑ ➤ ిؾૉࢠͷྼԽͳͲ͕ݪҼ ➤
#FIBWJPST͕Ұॠ͚ͩؒҧ͍ͬͯΔ৔߹͕͋Δ ➤ $001&3 ()"/%,3*4)/".635)* 4 ʠ&NCFEEJOHEZOBNJDEBUBGMPXJO BDBMMCZWBMVFMBOHVBHFʡ *O&401ʟ 1SPDFFEJOHTPGUIFUI&VSPQFBO DPOGFSFODFPO1SPHSBNNJOH-BOHVBHFT BOE4ZTUFNT4QSJOHFS7FSMBH #FSMJO )FJEFMCFSH r 12 -2.5 -2 -1.5 -1 -0.5 0 0.5 1 1.5 2 2.5 -1.6 -1.2 -0.8 -0.4 0.4 0.8 1.2 1.6 ిؾతͳάϦονͷΠϝʔδ

άϦονͱͦͷରࡦʢ̎ʣ ➤ άϦονͷྫ ➤ ࣍ͷΑ͏ͳϦΞΫςΟϒϓϩάϥϛϯάΛߟ͑ͯΈΔ ➤ WBS͕ʹมԽͨ࣌͠ͳʹ͕ى͖Δ͔ʁ ➤ ࿦ཧతʹ͸ɺWBS͸WBSͷഒʢWBSʷWBSʣ ➤
͔͠͠ɺΠϕϯτ഑ૹͷλΠϛϯά࣍ୈͰ͸ɺWBSʺʷWBSͱͳΔ 13 Glitch avoidance is another property that needs to be considered by a reactive language. Glitches are update inconsistencies that may occur during the propagation of changes. When a computation is run before all its dependent expressions are eval- uated, it may result in fresh values being combined with stale values, leading to a glitch [Cooper and Krishnamurthi 2006]. This can only happen in languages employ- ing a push-based evaluation model. Consider an example reactive program below: var1 = 1 var2 = var1 * 1 var3 = var1 + var2 In this example, the value of the variable var2 is expected to always be the same as that of var1, and that of var3 to always be twice that of var1. Initially when the value of var1 is 1, the value of var2 is 1 and var3 is 2. If the value of var1 changes to, say 2, the value of var2 is expected to change to 2 while the value of var3 is expected to be 4. However, in a naive reactive implementation, changing the value of var1 to 2 may cause the expression var1 + var2 to be recomputed before the expression var1 * 1. Thus the value of var3 will momentarily be 3, which is incorrect. Eventually, the expression var1 * 1 will be recomputed to give a new value to var2 and therefore the value of var3 will be recomputed again to reﬂect the correct value 4. This behaviour is depicted in Figure 3. In the reactive programming literature, such a momentary view of inconsistent data

άϦονͱͦͷରࡦʢ̏ʣ 14 A Survey on Reactive Programming 1 * 1
var1 1 var2 2 var3 + 2 * 1 var1 1 var2 3 var3 + 2 * 1 var1 2 var2 4 var3 + time var1 = 1 var2 = 1 var3 = 2 var1 = 2 var2 = 1 var3 = 3 var1 = 2 var2 = 2 var3 = 4 nges. When a computation is run before all its dependent expressions are eval- ed, it may result in fresh values being combined with stale values, leading to a ch [Cooper and Krishnamurthi 2006]. This can only happen in languages employ- a push-based evaluation model. onsider an example reactive program below: var1 = 1 var2 = var1 * 1 var3 = var1 + var2 n this example, the value of the variable var2 is expected to always be the same that of var1, and that of var3 to always be twice that of var1. Initially when the ue of var1 is 1, the value of var2 is 1 and var3 is 2. If the value of var1 changes to, 2, the value of var2 is expected to change to 2 while the value of var3 is expected be 4. However, in a naive reactive implementation, changing the value of var1 to ay cause the expression var1 + var2 to be recomputed before the expression var1 . Thus the value of var3 will momentarily be 3, which is incorrect. Eventually, the ression var1 * 1 will be recomputed to give a new value to var2 and therefore the ue of var3 will be recomputed again to reﬂect the correct value 4. This behaviour is icted in Figure 3. n the reactive programming literature, such a momentary view of inconsistent data nown as a glitch [Cooper and Krishnamurthi 2006]. Glitches result in incorrect pro- m state and wasteful recomputations and therefore should be avoided by the lan- ge. Most reactive programming languages eliminate glitches by arranging expres- ࠷ऴతʹ͸ਖ਼͍͠஋ʹ ෆඞཁͳܭࢉˍ஋ͷෆ੔߹

άϦονͱͦͷରࡦʢ̐ʣ ➤ UPQPMPHJDBMMZTPSUFEHSBQIͰղܾͰ͖ΔΒ͍͠ʢཁௐࠪʣ ➤ $001&3 ()"/%,3*4)/".635)* 4ʠ&NCFEEJOHEZOBNJDEBUBGMPXJOBDBMMCZWBMVFMBOHVBHFʡ *O&401ʟ1SPDFFEJOHT PGUIFUI&VSPQFBODPOGFSFODFPO1SPHSBNNJOH-BOHVBHFTBOE4ZTUFNT4QSJOHFS7FSMBH #FSMJO
)FJEFMCFSH r ➤ .&:&307*$) -" (6)" " #"4,*/ + $001&3 () (3&&/#&3( . #30.'*&-% " "/%,3*4)/".635)* 4ʠ'MBQKBYB QSPHSBNNJOHMBOHVBHFGPSBKBYBQQMJDBUJPOTʡ *O0014-"ʟ1SPDFFEJOHPGUIFUI"$.4*(1-"/DPOGFSFODFPO0CKFDUPSJFOUFE QSPHSBNNJOHTZTUFNTMBOHVBHFTBOEBQQMJDBUJPOT"$. /FX:PSL /: 64" r ➤ ."*&3 * 30.1' 5 "/%0%&34,: .ʠ%FQSFDBUJOHUIF0CTFSWFS1BUUFSOʡ 5FDISFQ ➤ ෼ࢄϦΞΫςΟϒϓϩάϥϛϯάͰ͸ະղܾͷ໰୊ ➤ ωοτϫʔΫো֐ ➤ ஗Ԇɺύέϩε ➤ άϩʔόϧΫϩοΫ͕ແ͍ ➤ ࠓޙͷݚڀ՝୊ 15

ϦϑςΟϯάͱͦͷઓུʢ̍ʣ ➤ طଘͷϗετݴޠʹϦΞΫςΟϒϓϩάϥϛϯά͕ಋೖ͞Εͨ৔߹ʹɺϦϑςΟϯ άͱݺ͹ΕΔૢ࡞͕ඞཁͱͳΔ ➤ ϦϑςΟϯάͰԿΛ͢Δ͔ʁ ➤ ʴɺʔɺˎɺʗͳͲͷϓϦϛςΟϒͳԋࢉʹର͢ΔϦΞΫςΟϒϓϩάϥϛϯά ରԠ ➤
ؔ਺ݺͼग़͠ʹର͢ΔϦΞΫςΟϒϓϩάϥϛϯάରԠ 16

ϦϑςΟϯάͱͦͷઓུʢ̎ʣ ➤ ϦϑςΟϯάͷఆٛ ➤ ➤ ͋ΔλΠϜεςοϓJʹ͓͍ͯ͸ɺϦΞΫςΟϒͰͳ͍ී௨ͷؔ਺ͱ౳Ձ 17 ments and
its return type) and it registers a dependency graph in the taflow graph. In the following definitions, we assume functions that haviour argument for the sake of brevity, generalising to functions le arguments is trivial. lift : f ( T ) ! flifted ( Behaviour < T > ) ys, Vol. , No. , Article , Publication date: 2012. ϦΞΫςΟϒͳ஋Λ ѻ͑ͳ͍ैདྷͷؔ਺Λ ϦΞΫςΟϒͳ஋ΛऔΔؔ਺ʹม׵ E. Bainomugisha et al. n, T is a non-behaviour type while Behaviour is a behaviour type ype T . Therefore, lifting an operator f that was defined to operate value transforms it into a lifted version flifted that can be applied aluation of a lifted function f called with a behaviour yielding values fined as follows: flifted ( Behaviour < T > ) ! f ( Ti ) the value of Behaviour at time step i . ween Typing and Lifting. In the body of work discussed in this survey, a number of different ways. Before discussing them, it is important interplay between the semantics of the host language and trans- ͜͜Ͱ5J͸λΠϜεςοϓJʹ͓͚Δ#FIBWJPSͷ஋

ϦϑςΟϯάͱͦͷઓུʢ̏ʣ ➤ ੩తܕ෇͚ݴޠʹର͢Δద༻ ➤ ੩తܕ෇͚ͳͷͰɺؔ਺Λ௚઀ม׵͢Δ͜ͱ͸ग़དྷͳ͍ ➤ ϓϩάϥϚ͕Ϧϑτૢ࡞Λߦ͏ඞཁ͕͋Δ ➤ Ұൠతʹ͸ݴޠͷఏڙ͢ΔΦʔόʔϩʔυͷػೳΛ༻͍ͯɺͳΔ΂͘؆୯ʹग़དྷΔΑ͏ ͳ޻෉͕͞Ε͍ͯΔ
➤ ಈతܕ෇͚ݴޠʹର͢Δద༻ ➤ ؔ਺ʹ͍ͭͯ͸ɺ#FIBWJPST΋ී௨ʹҾ਺ͱͯ͠ड͚औΕΔ ➤ ݴޠ಺෦Ͱ҉໧తʹॲཧ͞ΕΔ ➤ ϓϦϛςΟϒͳԋࢉʹ͍ͭͯ͸ɺԋࢉࢠΦʔόʔϩʔυ΍ɺίʔυੜ੒࣌ʹ޻෉͕ඞཁ 18

ϦϑςΟϯάͱͦͷઓུʢ̐ʣ ➤ ҉໧తϦϑςΟϯά ➤ ➤ ಈతܕ෇͚ݴޠͰ༻͍ΒΕΔख๏ ➤ ໌ࣔతϦϑςΟϯά ➤
➤ ੩తܕ෇͚ݴޠͰ༻͍ΒΕΔख๏ ➤ ΦʔόʔϩʔυͳͲͰରԠ͍ͯ͠Δ৔߹΋ͪ͜Βʹ෼ྨ ➤ खಈϦϑςΟϯά ➤ ➤ ݴޠϨϕϧͰͷαϙʔτແ͠ͷ৔߹͸ɺखಈͰݱࡏͷ#FIBWJPSTͷ஋ΛΘͨ͢ඞཁ͕͋Δ 19 mplicit lifting approach, when an ordinary language operator it is automatically “lifted”. Implicit lifting makes reactive , since programmers can freely use existing operators on f ( b1 ) ! flifted ( b1 ) ordinary operator f is applied on a behaviour b1 , it is implic- the approach undertaken by dynamically typed languages. plicit lifting, the language provides a set of combinators that ry operators to operate on behaviours. lift ( f )( b1 ) ! flifted ( b1 ) nary operator f is explicitly lifted using the combinator lift e behaviour b1 . This is the approach that is usually under- languages. In many cases, reactive programming systems f ( b1 ) ! flifted ( b1 ) an ordinary operator f is applied on a behaviour b1 , it is implic- is the approach undertaken by dynamically typed languages. xplicit lifting, the language provides a set of combinators that nary operators to operate on behaviours. lift ( f )( b1 ) ! flifted ( b1 ) dinary operator f is explicitly lifted using the combinator lift the behaviour b1 . This is the approach that is usually under- d languages. In many cases, reactive programming systems ACM Computing Surveys, Vol. , No. , Article , Publication date: 2012. ogramming :9 oblem domain, for which it offers a rich set of overloaded primi- rk on behaviours. In this survey, we still classify this as explicit n in the discussion of the language in question when primitive ded to deal with behaviours. th manual lifting, the language does not provide lifting operators. mer needs to manually obtain the current value of a time-varying be used with ordinary language operators. f ( b1 ) ! f ( currentvalue ( b1 )) current value of the time-varying value b1 is obtained that is then operator f . In languages that do not offer ﬁrst-class behaviours,

ଟํ޲ੑ ➤ Πϕϯτͷ఻ୡํ޲͕ɺҰํ޲͔૒ํ޲͔ ➤ ྫɿઁࢯ՚ࢯม׵ ➤ '$ˎʴ ➤ $͕มԽ͢Δͱ'ͷ஋͕มԽʢ͜͜·ͰҰํ޲ʣ ➤
্ͷ౳ࣜ͸࣍ͷΑ͏ʹม׵Ͱ͖Δ ➤ $ 'ʔ ➤ '͕มԽ͢Δͱ$΋มԽ͢Δͱ૒ํ޲ ➤ ੍໿ϓϩάϥϛϯάͱࣅ͍ͯΔ 20

෼ࢄϦΞΫςΟϒϓϩάϥϛϯά ➤ ෼ࢄ؀ڥͰͷϦΞΫςΟϒϓϩάϥϛϯά͸ୡ੒Ͱ͖Δ͔ʁ ➤ ໰୊఺ ➤ Ұ؏ੑͷอূ͕Ͱ͖Δͷ͔ʁ ➤ άϦονͷղܾ͕ߋʹ೉͘͠ ➤
άϩʔόϧΫϩοΫແ͠ ➤ ύέοτϩε ➤ ϨΠςϯγ 21

ϦΞΫςΟϒ ϓϩάϥϛϯάͷछྨ

Table I. A taxonomy of reactive programming languages Language Basic
abstractions Evaluation model Lifting Multidirectionality Glitch avoidance Support for distribution FRP Siblings Fran behaviours and events Pull Explicit N Y N Yampa signal functions and events Pull Explicit N Y N FrTime behaviours and events Push Implicit N Y N NewFran behaviours and events Push and Pull Explicit N Y N Frapp´ e behaviours and events Push Explicit N N N Scala.React signals and events Push Manual N Y N Flapjax behaviours and events Push Explicit and implicit N Y (local) Y AmbientTalk/R behaviours and events Push Implicit N Y (local) Y Cousins of Reactive Programming Cells rules, cells and ob- servers Push Manual N Y N Lamport Cells reactors and reporters Push and Pull Manual N N Y SuperGlue signals, components, and rules Push Manual N Y N Trellis cells and rules Push Manual N Y* N Radul/Sussman Propagators propagators and cells Push Manual Y N N Coherence reactions and actions Pull N/A Y Y N .NET Rx events Push Manual N N? N

ϦΞΫςΟϒϓϩάϥϛϯάͷ෼ྨ 24 12 E. Bainomugisha et a Programming languages for
expressing reactive systems Synchronous, dataflow and synchronous dataflow languages The cousins of reactive proramming The FRP siblings Fig. 4. Classification of languages for reactive programming. pen in one direction. We further discuss the support for multidirectionality in reactiv programming languages as an open issue in Section 5.

ؔ਺ܕϦΞΫςΟϒϓϩάϥϛϯά ➤ ؔ਺ͷҾ਺͕Πϕϯτ ➤ Ҿ਺ͷ஋͕มΘΔʢΠϕϯτ͕ൃੜ͢Δʣͱࣗಈతʹؔ਺͕ݺ͹ΕΔ ➤ ྫɿ ➤ ESBXDJSDMFNPVTFYNPVTFZ
➤ NPVTFYɺNPVTFZͷ஋͕มΘΔͱESBXDJSDMFؔ਺͕ࣗಈతʹݺ͹ΕΔ 25

ؔ਺ܕϦΞΫςΟϒϓϩάϥϛϯάͷछྨ 26 rvey on Reactive Programming Table II. Functional reactive
programming (FRP) siblings Language Host language Fran [Elliott and Hudak 1997] Haskell Yampa [Hudak et al. 2003] Haskell Frapp´ e [Courtney 2001] Java FrTime [Cooper and Krishnamurthi 2006] PLT Scheme (now known as Racket) NewFran [Elliott 2009] Haskell Flapjax [Meyerovich et al. 2009] JavaScript Scala.React [Maier et al. 2010] Scala AmbientTalk/R [Carreton et al. 2010] AmbientTalk posing events and switching combinators to support the dynamic reconfigura e dataflow and support higher-order dataflow.

ؔ਺ܕͰͳ͍ϦΞΫςΟϒϓϩάϥϛϯάͷछྨ 27 y on Reactive Programming Table III. The cousins
of reactive programming Language Host language Cells [Tilton 2008] CLOS Lamport Cells [Miller 2003] E SuperGlue [McDirmid and Hsieh 2006] Java Trellis [Eby 2008] Python Radul/Sussman Propagators [Radul and Sussman 2009] MIT/GNU Scheme Coherence [Edwards 2009] Coherence .NET Rx [Hamilton and Dyer 2010] C#.NET

ϦΞΫςΟϒ ϓϩάϥϛϯάͷ࣮ྫ

'SBO ➤ ೥ʹߟҊ͞ΕͨɺҰ൪ॳΊͷϦΞΫςΟϒϓϩάϥϛϯάݴޠ ➤ ϗετݴޠ͸)BTLFMM ➤ ؔ਺ܕϦΞΫςΟϒϓϩάϥϛϯά ➤ ϦϑςΟϯά͸໌ࣔతʹߦ͏ ➤
ͨͩ͠ɺଟ͘ͷ৔߹ͰΦʔόʔϩʔυͰରԠՄೳ ➤ ౰ॳ͸QVMMϕʔεͰͷ࣮૷ͩͬͨ ➤ ͋ͱͰQVTIʹ΋ରԠ ➤ &--*055 $.ʠ1VTIQVMMGVODUJPOBMSFBDUJWFQSPHSBNNJOHʡ *O1SPDFFEJOHTPGUIF OE"$.4*(1-"/TZNQPTJVNPO)BTLFMM)BTLFMMʟ"$. /FX:PSL /: 64" r 29

'SBOͷྫʢ̍ʣ ➤ ઁࢯ՚ࢯม׵ ➤ UFNQ͸ఆٛࡁΈͷCFIBWJPS 30 the need to explicitly
lift operators for this particular problem dom The first implementation of Fran employs a purely pull-based However, the recent implementation of Fran [Elliott 2009] (th NewFran in this paper), combines push- and pull-based evaluation bination of these models yields the benefit of values being recompu are necessary, and almost instantaneous reactions. The temperatur ple can be realised in Fran as follows. tempConverter :: Behavior Double tempConverter = tempF where tempC = temp tempF = (tempC*1.8)+32 tempConverter is a function that returns a behaviour whose value in time is the value of the current temperature in degrees Fahrenhe there is a predefined behaviour temp whose value at any given t temperature in degrees Celsius. In order to illustrate Fran’s support for the dynamic dataflow s UFNQͷ஋͕มΘΔͱUFNQ$POWFSUFSͷ஋΋ࣗಈతʹมΘΔ

'SBOͷྫʢ̎ʣ ➤ ԁΛॻؔ͘਺ ➤ MCQɺSCQ͸FWFOU ➤ XJUI$PMPS͸ඳըؔ਺ ➤ DJSDMF͸ࣄલʹఆٛ͞ΕͨCFIBWJPS 31
where tempC = temp tempF = (tempC*1.8)+32 tempConverter is a function that returns a behaviour whose value at any given point in time is the value of the current temperature in degrees Fahrenheit. We assume that there is a predefined behaviour temp whose value at any given time is the current temperature in degrees Celsius. In order to illustrate Fran’s support for the dynamic dataflow structure and high- order reactivity, we consider an example of drawing a circle on the screen and painting it red. The colour of the circle then changes to either green when the left mouse button is pressed or red when the right mouse button is pressed. This example also appears in [Elliott and Hudak 1997]. Such a program in Fran can be easily expressed as follows: drawcircle :: ImageB drawcircle = withColour colour circle where colour = stepper red (lbp -=> green .|. rbp -=> red) In the above example, circle is a predefined behaviour for a circle while lbp and rbp are events that represent left button presses and right button presses respectively. The merge operator .|. produces events when either input events have an occurrence. We use the stepper combinator to create the colour behaviour that starts with red until the first button press at which point it changes to either green or red. withColour is ࠨϘλϯΫϦοΫͳΒ྘ʹ ӈϘλϯΫϦοΫͳΒ੺ʹ ॳظ஋

'MBQKBYͷྫʢ̍ʣ ➤ +BWB4DSJQU্Ͱ'31Λ࣮ݱ ➤ QVTIϕʔε ➤ ؔ਺ܕϦΞΫςΟϒϓϩάϥϛϯά 32 The tempConverter
function implements the functionality of converting temperature from degrees Celsius to degrees Fahrenheit. We assume that there is a predeﬁned behaviour Temperature whose value at any given point in time is the current temperature. The insertValueB function inserts the values of the behaviours tempC and tempF in the DOM elements. We further illustrate Flapjax’s support for ﬁrst-class behaviours and primitive combinators using the example of drawing on a circle a screen that changes colour depend- ing on whether a left or right mouse button is pressed. The example can be expressed as follows. //draw circle at (x,y) and paint it colour function drawcircle(x, y, colour) {...}; //map button press to colour function handleMouseEvent(evt) {...}; var buttonE = extractEventE(document,"mousedown"); var colourE = buttonE.mapE(handleMouseEvent); var colourB = startsWith(colourE, "red"); var canvas = document.getElementById(’draw’); drawcircle(mouseLeftB(canvas), mouseTopB(canvas), colourB); In the above example, we use Flapjax’s combinators extractEventE and mapE to ex- tract mousedown events from the DOM and transform them into colour events. The CFIBWJPST FWFOUT MJGUJOH Ͳ͏͍͏࢓૊͔Θ͔Βͳ͍͚ΕͲɺDPMPVS#͕มߋ͞ΕͨΓɺ Ϧυϩʔ͢Δͱ͖ʹɺESBXDJSDMF͕ݺͼग़͞ΕΔɻ͍͢͝ɻ

'MBQKBYͷྫʢ̎ʣ ➤ IUUQXXXGMBQKBYMBOHPSHUSZJOEFYIUNM FEJUNPVTF@DPPSETGY ➤ Ϛ΢εΛಈ͔͢ͱ)5.-͕উखʹߋ৽͞ΕΔಾٕज़ 33 <html> <head> <title>Flapjax
Demo: Where is the Mouse?</title> <link rel="stylesheet" href="/demo.css"/> </head> <body> <p>The mouse coordinates are < {! mouseLeftB(document) !}, {! mouseTopB(document) !} > </p> </body> </html>

5SFMMJTͷྫ ➤ 1ZUIPO্Ͱߏங͞ΕͨɺϦΞΫςΟϒϓϩάϥϛϯά؀ڥ ➤ HMJDIճආ͸෦෼తʹ͞Ε͍ͯΔ͕ɺ׬શͰ͸ͳ͍Β͍͠ʁʢৄࡉ͸ௐ΂͍ͯͳ͍ʣ ➤ QVTIܕͷϞσϧ ➤ ؔ਺ܕ͡Όͳ͍ϦΞΫςΟϒϓϩάϥϛϯά 34
:26 E. Bainomugisha et al. class TempConverter(trellis.Component): tempC = trellis.attr(Temperature) tempF = trellis.maintain( lambda self: self.tempC * 1.8 + 32, initially = 32 ) @trellis.perform def viewGUI(self): display "Celsius: ", self.tempC display "Fahrenheit: ", self.tempF ࣄલʹఆٛ͞Εͨม਺ʢΠϕϯτʣʹؔ࿈͚ͮ

/&539ͷྫ ➤ ౷߹ݴޠΫΤϦ-*/2্ʹߏங͞Εͨ/&5֦ு ➤ Πϕϯτιʔεʹରͯ͠ɺ*0CTFSWBCMF5ͱ͍͏δΣωϦοΫΠϯλʔϑΣʔεΛఏڙ ➤ *0CTFSWBCMF5͸ɺΠϕϯτΦϒβʔόΛొ࿥͢ΔͨΊͷϝιου4VCTDSJCFΛఏڙ ➤ QVTIܕͷϞσϧ ➤
HMJDIʹؔͯ͠͸ෆ໌ʢ/P ͱ࿦จʹॻ͍ͯ͋Δʣ ➤ ؔ਺ܕ͡Όͳ͍ϦΞΫςΟϒϓϩάϥϛϯά 35 .NET Rx [Hamilton and Dyer 2010] is a reactive programming extension to It is built on top of LINQ [Microsoft 2007], a project that adds query fa to the .NET Framework. As in Scala.React, .NET Rx provides a generic in IObservable<T> for representing event sources. The IObservable interface prov method Subscribe that enables one to register a closure that will be executed w event occurs. In addition, .NET Rx allows event composition. New speciﬁc even be created from general events using the rich set of LINQ combinators (e.g., agg selection, joins, etc.). The propagation of events in .NET Rx is based on the push model. Consume ister interest in particular event types and then the events are pushed to them they occur. This work is still ongoing and from the available documentation it explained if the language achieves glitch freedom. The temperature conversion example can be realised in .NET Rx as follows. var temperature = new Temperature(); temperature.Subscribe( temp => { var tempC = temp.currentTemperature; var tempF = (tempC*1.8)+32; }) *0CTFSWBCBMF5Λ࣮૷ͨ͠Ϋϥε

·ͱΊ

·ͱΊ ➤ ϦΞΫςΟϒϓϩάϥϛϯάͱ͍͏ϓϩάϥϛϯάύϥμΠϜΛ঺հ ➤ ೥ʹొ৔ͱɺݴޠͷϞσϧͱͯ͠͸ൺֱత৽͍͠ ➤ ΦϒδΣΫτࢦ޲ɿ೥ɺ4JNVMBݴޠ ➤ δΣωϦοΫϓϩάϥϛϯάɿ೥ ➤
.VTTFS %34UFQBOPW "" (FOFSJDQSPHSBNNJOH*O1(JBOOJ4ZNCPMJDBOE"MHFCSBJD $PNQVUBUJPO*OUFSOBUJPOBMTZNQPTJVN*44"$-FDUVSF/PUFTJO$PNQVUFS4DJFODFQQr EPJ@*4#/ ➤ ΠϕϯτΛந৅Խͯ͠هड़Ͱ͖Δ ➤ ෳࡶͳΠϕϯτͷૢ࡞΋؆୯ʹͳΔΒ͍͠ ➤ (6*ͳͲͰେ׆༂ 37

&0' 38

リアクティブプログラミング

リアクティブプログラミング

More Decks by ytakano

Other Decks in Programming

Featured

Transcript