tag:blogger.com,1999:blog-2267747408703654731.post4647385221965628479..comments2017-12-12T01:39:57.752-08:00Comments on Prettt-tty, pretty, pretty good!: Reification of time in FRP is a conceptual errorPaul Chiusanohttp://www.blogger.com/profile/04844651950877109501noreply@blogger.comBlogger34125tag:blogger.com,1999:blog-2267747408703654731.post-2930249572739582272016-05-12T01:41:53.955-07:002016-05-12T01:41:53.955-07:00How do you define the Category instance if m is no...How do you define the Category instance if m is not a monad?Manuel Bärenzhttps://www.blogger.com/profile/13026488895635508651noreply@blogger.comtag:blogger.com,1999:blog-2267747408703654731.post-89579354373709557262010-12-13T12:52:16.347-08:002010-12-13T12:52:16.347-08:00(I am the previous Anon, great blogs by the way)
...(I am the previous Anon, great blogs by the way)<br /><br />One important thing to realize is that a model exists only within its interpretation. The "interpretation" of FRP models assumes that some variables can be piecewise continuous, changing with time. It also assumes that discrete events can happen and that these events possibly cause discontinuities to those variables (that is why they are piecewise continuous). <br />When you consider the model as code, you can bring in type theory and do nice things; FRP demonstrates that well.<br />When you consider the model as mathematical properties, you can bring in analysis and also do nice things. For example, it might be easier to model a system in frequency domain. In frequency domain, time disappears and making time reification is less obvious. <br />I mentioned wavelets, because time “partially disappears”: the wavelet constructs hierarchy of time/frequency Cartesian products. In such a context, time is no longer continuous, but discretized in a hierarchy. Your model could express wavelet properties, and deal with events (which would need to be aligned with the time discretization/frequency domain. But my feeling is that the time reification would meet its limits in such a case.equationalhttps://www.blogger.com/profile/10819829890370317060noreply@blogger.comtag:blogger.com,1999:blog-2267747408703654731.post-41763207077342517052010-12-12T09:14:32.970-08:002010-12-12T09:14:32.970-08:00@Anon - Can you elaborate on "Yet if you view...@Anon - Can you elaborate on "Yet if you view the world in some "wavelet" like decomposition where the world is a structured combination of time and space characteristics, then the FRP time model probably meets its limits. Moving to a quantum world is worse." It sounds very interesting but I'm not really sure what you're talking about. :)Paul Chiusanohttps://www.blogger.com/profile/04844651950877109501noreply@blogger.comtag:blogger.com,1999:blog-2267747408703654731.post-34146601449583420702010-12-10T00:39:33.499-08:002010-12-10T00:39:33.499-08:00FRP time modeling is not right or wrong, it is the...FRP time modeling is not right or wrong, it is the way it is. And for each way you choose to model somthing, there will be the pros and cons. Time is continuous and monoticaly increasing, and would seem to be the reason for the FRP modeling. Yet if you view the world in some "wavelet" like decomposition where the world is a structured combination of time and space characteristics, then the FRP time model probably meets its limits. Moving to a quantum world is worse.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-2267747408703654731.post-4698918467219923882010-11-16T19:04:13.927-08:002010-11-16T19:04:13.927-08:00Ben: I agree with what you say about the way thing...Ben: I agree with what you say about the way things are implemented "in most simulations". And I see that standard way as an unfortunate low-levelness of those implementations. That is, most simulations are non-modular in this way: the specification of the continuous behavior is not separated out from the implementation of numerical solution/approximation methods for those specifications. Rather, these two conceptually separable aspects are enmeshed.<br /><br />In a high-level, modular simulation program, I expect we'd see a lot more of continuous time, and I don't think we would <i>ever</i> see "dt" or "previous state" in the specifications of behavior.Conalhttps://www.blogger.com/profile/05756984502464196668noreply@blogger.comtag:blogger.com,1999:blog-2267747408703654731.post-35520891672435914832010-11-16T18:20:46.499-08:002010-11-16T18:20:46.499-08:00flippac,
in most simulations:
S' = f(S, dt)
...flippac,<br />in most simulations:<br /><br />S' = f(S, dt)<br /><br />where S' is a state subsequent to state S, and dt is the time step between them.<br /><br />While dt appears here, t (ie time) does not. Ultimately, /subsequent states/ can be computed from /previous states/. The difference between a continuous or discrete simulation is whether dt is fixed or variable.Ben Hutchisonhttps://www.blogger.com/profile/04698002385923057473noreply@blogger.comtag:blogger.com,1999:blog-2267747408703654731.post-84315237501442490362010-11-16T16:13:01.870-08:002010-11-16T16:13:01.870-08:00Part of the point of FRP is to express things that...Part of the point of FRP is to express things that vary continuously over time - not just a series of sampled frames showing where a ball is after it's thrown every 1/60th of a second but the entire curve. How can you do this without the notion of time being a significant part of the system? Many values can and will depend directly on time or an integral with respect to it.<br /><br />If all you need is a discrete event system then yes, FRP is more than you need.flippachttp://flippac.dreamwidth.org/noreply@blogger.comtag:blogger.com,1999:blog-2267747408703654731.post-91644481679994305182010-08-05T13:20:56.065-07:002010-08-05T13:20:56.065-07:00@conal - I did check out those references. I had s...@conal - I did check out those references. I had seen your TCM paper before and also Luke Palmer's semantic design post, but I went back and took a closer look in light of our current discussion. The discussion of your TCM paper on LtU was actually quite helpful - it seems like I am saying something similar to Matt M: http://lambda-the-ultimate.org/node/3215#comment-47263 but it is hard to tell for sure. <br /><br />Your criteria for why you'd choose one mathematical object over another for your denotation seem reasonable, though quite subjective (not a bad thing necessarily). <br /><br />As for why I see T as being ill-defined... I find this hard to explain without just repeating myself... ill-defined is probably not the best way to say it - it is more that T by itself in the (T -> a) -> (T -> b) model does not really nail down what sorts of programs should be expressible without making further assumptions. At this point, I would like to read up more about the distinction between the different types of semantics (denotational, algebraic, ...) since that seems to be the heart of where we might differ and I feel like I am handwaving - if you can recommend any good resources let me know (Derek Elkins on LtU pointed to this book: http://www.cs.uiowa.edu/~slonnegr/plf/Book/). And I'd like to just generally collect my thoughts and perhaps write them up, using a less contentious example than FRP. Then maybe we can continue the discussion. :) <br /><br />Thanks for the comments.Paul Chiusanohttps://www.blogger.com/profile/04844651950877109501noreply@blogger.comtag:blogger.com,1999:blog-2267747408703654731.post-70650006699479562252010-08-03T17:30:01.465-07:002010-08-03T17:30:01.465-07:00Hi Paul:
From your latest remarks I can't tel...Hi Paul:<br /><br />From your latest remarks I can't tell whether you understood or even read my previous response. I'd like to hear your responses to the answers I offered there: denotational design criteria, dataflow graphs, (in)completeness (non-specificity) of algebras, references to my TCM paper an an LTU thread, etc. And if you don't understand those answers, please ask for clarification.<br /><br />Also, I'm puzzled about how you could not see T as well-defined. I expect that every single paper that gives a denotational semantics for FRP (whether classic or arrow) answers that question, and there are many such papers. A hand-waving explanation could fail to define T, and an algebraic approach (as you advocate) could also fail to define T. A denotational will answer your questions. Which illustrates one of the points I made in my previous response about why denotational.Conalhttps://www.blogger.com/profile/05756984502464196668noreply@blogger.comtag:blogger.com,1999:blog-2267747408703654731.post-79191120509739124472010-08-03T15:52:51.419-07:002010-08-03T15:52:51.419-07:00@conal and @wren - Yes, I think this discussion is...@conal and @wren - Yes, I think this discussion is deeper than I'd realized. :) I think of there as being two perspectives: On the one hand, we start with the algebra, and figure out what operations and primitives we want to be able to express and what relationships we expect to hold among the expressions of this algebra. In the other approach, we start with what we want our expressions to mean, then work from there to determine an algebra. <br /><br />Are these two really that different though? One way to view the meaning-first-approach is that you are mapping your expressions to some other mathematical object with a well-known algebra, so it's still "algebra first". On the other hand, with the algebra-first-approach, you might argue that you are at least vaguely thinking of some possible denotation for your expressions, and this guides the choice of operators and such, so it's still "meaning-first"!<br /><br />I think I'd be more comfortable with (T -> a) -> (T -> b) as a model if T were actually something well-defined. As it stands, it has no algebra, and so this model tells me nothing about the sorts of things that are or should be expressible in this model. That question will be answered by the set of combinators we end up exposing (i.e, the algebra), and for me this is where the real work is. For instance, if T is opaque, with no defined operations - like in forall t . (t -> a) -> (t -> b), then it is impossible to construct time varying functions at all! If t is a ring, it permits functions that can reach into the past or look into the future (by that I mean, there are conceivable functions of that type).<br /><br />Conal, I suspect if the semantic domain were something with an obvious algebra, we would not be disagreeing much since we'd have worked from different directions but met in the middle. :)<br /><br />By the way, great discussion guys. :)Paul Chiusanohttps://www.blogger.com/profile/04844651950877109501noreply@blogger.comtag:blogger.com,1999:blog-2267747408703654731.post-62980364775853637712010-08-03T14:26:26.925-07:002010-08-03T14:26:26.925-07:00@dlandauer - fixed, thanks :)@dlandauer - fixed, thanks :)Paul Chiusanohttps://www.blogger.com/profile/04844651950877109501noreply@blogger.comtag:blogger.com,1999:blog-2267747408703654731.post-11909080133607634352010-08-03T10:01:55.216-07:002010-08-03T10:01:55.216-07:00Typo: causal is written as "casual" in ...Typo: causal is written as "casual" in the anchor text of your link to the CCA paper.dlandauerhttps://www.blogger.com/profile/04517193778611033674noreply@blogger.comtag:blogger.com,1999:blog-2267747408703654731.post-35358294217670028652010-08-03T02:22:07.713-07:002010-08-03T02:22:07.713-07:00@paul re @conal: Part of the reason it's an in...@paul re @conal: Part of the reason it's an interesting question is because the question is not "how do I write games in a pure language?" but rather "what does it mean to write games purely?". Essential to the latter question is that funny word <i>means</i>.<br /><br />You're positing that it is unnecessary to find a model, so long as we can find an algebra. Whether this is indeed adequate is related to a long argument between semanticists and proof theoreticians. That is, the question of whether a proof theoretic system should count as a "semantics" or whether only model theoretic systems can. This in turn is related to the question of what it means for an algebraic system to be "sound" or "complete". Generally, these are phrased as an algebraic system being sound and complete with respect to some semantic model. I won't raise my opinions on this debate, since they're not relevant here, but you should be aware that your question is perhaps deeper than you intended.<br /><br />In line with a comment dons made over on reddit, the interesting thing about FRP is <i>not</i> that it offers a solution to how to write games etc in Haskell. Certainly it's interesting if FRP does enable us to do that, and certainly we would like for it to, but it's not (so far as I understand) the true goal. The true goal is to figure out an answer to the question of meaning: what is it that games etc mean, why have their semantics eluded us for so long, and is it possible to capture those semantics in a pure system. All of these are very interesting questions, which is why FRP is an interesting area for research.wrenhttps://www.blogger.com/profile/05766067924472271354noreply@blogger.comtag:blogger.com,1999:blog-2267747408703654731.post-47606718671740630762010-08-02T20:53:21.066-07:002010-08-02T20:53:21.066-07:00> We can place the expressions of our program i...> We can place the expressions of our program in correspondence with many different mathematical objects... why choose one object over another?<br /><br />I have a few criteria I use to answer this question:<br /><br />* Mathematical precision. Base requirement.<br /><br />* Adequacy. Must cover the whole programming interface and explain properties, such as nontrivial equivalences.<br /><br />* Simplicity. Relative measure, i.e., simpler is better.<br /><br />See also Luke Palmer's post <a href="http://lukepalmer.wordpress.com/2008/07/18/semantic-design/" rel="nofollow">Semantic Design</a>.<br /><br />Of critical importance is to measure simplicity after the first two criteria are satisfied. Don't measure simplicity of a hand-wavy notion, and do not assume that your hand-waving-based guess about simplicity is at all close to the measure after you've replaced fuzzy thinking with precise thinking.<br /><br />"Everything is vague to a degree you do not realize till you have tried to make it precise." - Bertrand Russell<br /><br /><br />> Why functions (T -> a) -> (T -> b) instead of dataflow graphs, say?<br /><br />Apply my three criteria above. First we'd have to make "dataflow graphs" precise. If we give a "graph" answer (set of nodes & edges), then we won't get nontrivial equivalences. Once you accomplish precision & adequacy, then we can examine simplicity.<br /><br />I like about (T -> a) -> (T -> b) is that it simply says: time-varying output that depends on time-varying input.<br /><br />> isn't it the algebra - the operations and the laws that govern them that aid in reasoning? [...]<br /><br />Does the algebra completely specify the semantics? If so, it's not a terribly useful algebra (describing only one thing). If not, how do you know what to implement?<br /><br />On the other hand, a denotational model tells you exactly <em>what</em> to implement, without constraining <em>how</em> you implement it. And it gives you a basis for proving algebraic properties. Fitting into patterns defined by algebraic concepts (Monoid, Applicative, Arrow, etc) gives helpful design feedback. It guides the design toward universals and away from the arbitrary. See <em><a href="http://conal.net/papers/type-class-morphisms/" rel="nofollow">Denotational design with type class morphisms</a></em>, especially footnote 1 and the John Reynolds quote in the conclusion section.<br /><br />You can also read a related discussion on <a href="http://lambda-the-ultimate.org/node/3215" rel="nofollow">an LTU thread</a>.<br /><br />> You think of the CCA algebra as being secondary... something you can use to implement a denotational model.<br /><br />Not to implement a denotational model, but rather to structure its interface and to give feedback on its elegance. See comments above.Conalhttps://www.blogger.com/profile/05756984502464196668noreply@blogger.comtag:blogger.com,1999:blog-2267747408703654731.post-12819155494174540472010-08-02T17:55:05.949-07:002010-08-02T17:55:05.949-07:00I agree with the main thrust of your argument. I h...I agree with the main thrust of your argument. I have been troubled by the "reification of time" concept in FRP myself, and feel that this wrong-turn may have limited the growth of FRP approaches.<br /><br />I think FRP should seek to declaratively relate the change in state to the current state, along the lines of autonomous dynamical systems:<br /><br />d( x(t) )/dt = f( x(t) )Ben Hutchisonhttps://www.blogger.com/profile/04698002385923057473noreply@blogger.comtag:blogger.com,1999:blog-2267747408703654731.post-61356013857806226792010-08-02T17:08:41.166-07:002010-08-02T17:08:41.166-07:00@conal - There is something I am uncomfortable wit...@conal - There is something I am uncomfortable with here.. but I can't quite put my finger on it... and perhaps I am misunderstanding what you are saying when you talk about finding a good denotational model first. :) But there seems to be some arbitrariness in what you assign to be "the" meaning of a functional reactive program (or any program). We can place the expressions of our program in correspondence with many different mathematical objects... why choose one object over another? Why functions (T -> a) -> (T -> b) instead of dataflow graphs, say? It seems the only answer is that some objects aid in thought more than others... but why is this the case?<br /><br />And why is this exercise so important in the first place? Perhaps this is more of a general difference in how one looks at these things... isn't it the algebra - the operations and the laws that govern them that aid in reasoning? The algebra is what lets you prove things about your programs... the denotation itself doesn't seem to help here... or, rather, it helps only insofar as it maps the expression to some object with a meaningful/useful algebra (but if that is the case, why deal with the objects at all? Why not just deal directly with the algebra?). I think of this as a category-theoryish perspective... we shouldn't care what the expressions ARE internally or what they mean, we care how they relate to other expressions - i.e, the algebra. You think of the CCA algebra as being secondary... something you can use to implement a denotational model. But another way of looking at it is that the algebra is primary, and our denotational model is secondary, just one of many models satisfying the CCA laws...<br /><br />Okay, I am done rambling. :)Paul Chiusanohttps://www.blogger.com/profile/04844651950877109501noreply@blogger.comtag:blogger.com,1999:blog-2267747408703654731.post-50670106010599851232010-08-02T12:59:45.899-07:002010-08-02T12:59:45.899-07:00> to have something just be a function of time ...> to have something just be a function of time might not be the most meaningful perspective... it says nothing about what is causing the evolution wrt time.<br /><br />Right, and wonderfully so! The <em>semantic model</em> for behavior says nothing about what <em>causes</em> a particular behavior to be what it is nor what computerish mechanisms get involved in implementation behavior (e.g., "processes and their dependencies", to borrow from your post). Similarly, the semantic model we call "numbers" says nothing about how particular numbers come to be. Consider the numeric program "seven = 3 + 4". You might object that the model of numbers fails to explain the "causal" relationship between 3, 4, and 7, and that "it obscures the real story (...) behind an opaque and ill-defined notion", omitting operational concerns like order of evaluation, binary representations, little- vs big-endianness, etc. And that a mathematical (rather than computer-oriented) notion of numbers involves "unimplementable gobbledeygook".<br /><br />> in many cases you don't want to model things explicitly, they are just black boxes... but in a programming system, one that can actually be executed, these dependencies will need to be discovered somehow. Is this purely an implementation concern?<br /><br />Yes. Purely an implementation concern.<br /><br />I like to define a simple & precise denotational model for each abstraction, completely separate from implementation concerns. This model gives a compelling & tractable basis for (a) clear & correct reasoning about uses of the abstraction, and (b) correct and efficient implementations of the abstraction.<br /><br />> I am curious what you think about CCAs... my interpretation is that it does not really make sense with CCAs to even talk about what they mean. CCAs satisfy the laws given, beyond that no meaning is assigned.<br /><br />Agreed. CCA is like Monoid, Group, and Monad: a signature and set of laws, and nothing else. And CCA is not FRP, just as Applicative is not FRP. (And Group is not number.) Rather, CCA and Applicative are two type classes among many that can help to organize FRP. Which leaves the question: what is FRP? For me, FRP is exactly the denotational model. More accurately, there are a few denotational models and hence a few FRPs. Type classs are <em>too little</em> to capture FRP (as you & I have just pointed out with CCA and Applicative). Implementation notions like "dependency" and "process" are <em>too much</em> to capture FRP, since they impose non-essential constraints and complications.<br /><br />So CCA is not an alternative to denotational thinking & precision. It's a delightful & useful algebraic packaging that fits with the denotational model(s) I think of as being FRP.<br /><br />Putting on my implementor hat, I next get interested in how I might get a FRP (i.e., a simple & precise denotational model) to execute on a machine.Conalhttps://www.blogger.com/profile/05756984502464196668noreply@blogger.comtag:blogger.com,1999:blog-2267747408703654731.post-75828388643888397682010-08-02T11:27:19.084-07:002010-08-02T11:27:19.084-07:00Once again I am blown away by the responses! :)
@...Once again I am blown away by the responses! :)<br /><br />@wren, thanks for your long, thoughtful replies. Your last post really clarified the distinction between the two points of view... one is not more valid than the other. I think of them as the "push" and "pull" views. The "pull" view is more analogous to conceptual model I complained about, the push view is akin to arrowized FRP. I can see how a "pull" view could work, but it seems to require more of a runtime to avoid space leaks, etc. But I would definitely not rule it out.<br /><br />@conal - Yes, I follow. I guess what I am saying is, time is rather opaque... so to have something just be a function of time might not be the most meaningful perspective... it says nothing about what is causing the evolution wrt time. It's fine if you just don't want to model this - in many cases you don't want to model things explicitly, they are just black boxes... but in a programming system, one that can actually be executed, these dependencies will need to be discovered somehow. Is this purely an implementation concern? I am curious what you think about CCAs... my interpretation is that it does not really make sense with CCAs to even talk about what they mean. CCAs satisfy the laws given, beyond that no meaning is assigned. The SF type just happens to be one type (but not the only) which satisfies the laws.<br /><br />Sorry about the problems posting comments - it looks like google has been having some issues lately:<br />http://www.google.com/support/forum/p/blogger/thread?tid=3b68bd1995999497&hl=enPaul Chiusanohttps://www.blogger.com/profile/04844651950877109501noreply@blogger.comtag:blogger.com,1999:blog-2267747408703654731.post-10470256361443440902010-08-02T00:10:43.567-07:002010-08-02T00:10:43.567-07:00@Paul
Nope, you don't have to model the "...@Paul<br /><br />Nope, you don't have to model the "actual dependencies" (it's not even clear what that is).<br /><br />For instance, take a ray of light. The <a href="http://en.wikipedia.org/wiki/Principle_of_least_action" rel="nofollow">principle of least action</a> is an equivalent formulation of its laws of motion and states that between two points, the path taken by the light ray is the one that has minimal length. Fixing the start and endpoint first and then looking at the movement in between is wholly counterintuitive in terms of "dependencies", but it's an equally valid description.<br /><br />In short, "time dependence", which means "time varying", is just a model, and it neatly separates out the business of describing what motion is and calculating it (knowledge of the dependencies can help with the latter, but does not need to).Heinrich Apfelmushttp://apfelmus.nfshost.comnoreply@blogger.comtag:blogger.com,1999:blog-2267747408703654731.post-66090122876918162102010-08-01T19:44:46.035-07:002010-08-01T19:44:46.035-07:00Hi Paul,
Based on your post and your replies, I d...Hi Paul,<br /><br />Based on your post and your replies, I do think you're reading something into "depends on time" and "function of time", adding some causal & operational associations that I never intended. Additional phrasings are "time-varying" or simply "varying". With these phrases, I'm trying to convey exactly the same meaning, which is exactly the simple notion of "function" in math. No notion of "because" (causal) or "how" (operational). Nothing about algorithms, code, formulas (closed-form or otherwise).<br /><br />Does this clarification help at all?<br /><br />Over the years I've noticed some people have the sort of discomfort you've expressed here. I think mainly they've overlaid operational thinking onto understanding what FRP is, i.e., mixing together <em>how</em> FRP programs might execute on a sequential computer with <em>what</em> FRP programs mean, independent of execution.<br /><br />In your Pipe types and the CCA paper's SF type, I see operational models. Nice tools for thinking about <em>how</em>, but not at all appealing to me for defining <em>what</em>. I always want simple, precise & compelling denotation first. And then consider many possible operational approaches for correctly implementing the denotation.Conalhttps://www.blogger.com/profile/05756984502464196668noreply@blogger.comtag:blogger.com,1999:blog-2267747408703654731.post-15726791893999095142010-08-01T16:19:27.151-07:002010-08-01T16:19:27.151-07:00Here's another take: A decent FRP should be ab...Here's another take: A decent FRP should be able to implement simple physics easily. Implementing a simple model of physics necessarily means introducing the relationship of acceleration and position and velocity, etc. This means integrals and derivatives with respect to, at least, time.<br /><br />So if you think that some form of integration and derivation should be, if not primitive, then at least trivally constructed from primitive operations, then time becomes something special.sclvnoreply@blogger.comtag:blogger.com,1999:blog-2267747408703654731.post-61357611127526477332010-08-01T15:34:26.462-07:002010-08-01T15:34:26.462-07:00It has been suggested that the type should really ...It has been suggested that the type should really be something like:<br /><br><br />frp :: Ord t => (t -> a) -> (t -> b)<br /><br><br />Then we can still state requirements like: "The value of frp f x must depend only on f y for y < x" without reifying time.<br /><br><br />Does that help?Yitznoreply@blogger.comtag:blogger.com,1999:blog-2267747408703654731.post-44245010213262229122010-08-01T15:01:05.515-07:002010-08-01T15:01:05.515-07:00Also, your blogger seems broken. It doesn't ac...Also, your blogger seems broken. It doesn't accept OpenID (error code bX-ywtyjz), and when using Google accounts it gives an error page, but then posts the comment anyways.wrenhttps://www.blogger.com/profile/05766067924472271354noreply@blogger.comtag:blogger.com,1999:blog-2267747408703654731.post-34678025824041895322010-08-01T14:58:49.395-07:002010-08-01T14:58:49.395-07:00As I mentioned before, I can't speak for the F...As I mentioned before, I can't speak for the FRPers since I've only followed them from a distance. However, my masters thesis was designing and working on a logic programming language (Dyna2) that uses the notion of "declarative truth maintenance" in order to retain purity despite an external process that can change the facts dynamically.<br /><br />The traditional FRP perspective where we take time-dependent values as our primitive type and provide combinators for manipulating them is extremely reminiscent of monads. Monads encapsulate a design pattern of structured values. For example, lists contain not just one value, but a collection of values structured in a particular way, and we preserve that structure through the use of the monadic primitives. But fundamentally, monads take a view from outside of the structure. We don't know the structure we're preserving, we just know a few primitive ways of manipulating this contraption we're given.<br /><br />The alternative is to adopt a perspective from within the structure, and looking out. That is, programs and values embedded within some larger context. Programs in context can manipulate vanilla values just like normal, but they also have a set of primitives for being able to move around their context. These operations for adjusting the context are just as primitive and inscrutable as the monadic ones for adjusting structure. This alternative perspective is essentially the one provided by comonads.<br /><br />In Dyna2, we are clearly running a program in context, namely the context of the external program that can alter our facts. We don't happen to have any primitives for altering the context within Dyna, but we are able to notice when the context changes. However, from the perspective of Dyna it is not so much that we say "hey, my environment changed!" and then make changes. Instead, we are informed that certain things are out of date and we add it to our work queue, just like we add things when we've derived a new fact and need to determine whether inference rules would allow us to derive something new from it. That is, from the perspective of Dyna itself, "the truth" is something that is considered stable and unchanging; it's just that we're forever running trying to reach it and maintain it.<br /><br />The dichotomy between traditional FRP and the atemporal version seems very similar to this. That is, in FRP we have structured objects that we pass around and manipulate from the outside. And because we are, in a sense, "outside of time" we need for the structures themselves to embody the notion of time. Whereas, from the atemporal perspective our programs are existing within those structures and looking out; because we are deeply embedded within time, we do not notice that we ourselves are changing in time, instead we only see the world changing around us. We are always chasing the present just like Dyna is always chasing the truth.<br /><br />Just like monads have a notion of being "in the monad" and then "running the monad", comonads have the same. Inside of Dyna we have a certain perspective, but Dyna would be uninteresting were not for that external program that runs it. In a similar way, CCA is uninteresting without some sort of outside causative agent to drive things; <i>sui causa non est</i>. Ultimately, the 'atemporal' perspective must still have some notion of time, it's just that time gets moved from the "inside" half of things to the "outside" half. Thus, from the inside we take a relativistic rather than absolute view of time. In the general field of modeling and simulation, the choice between objectivity and subjectivity isn't one that has an absolute answer. They each have different strengths and weaknesses, so the choice depends on what it is you're modeling.wrenhttps://www.blogger.com/profile/05766067924472271354noreply@blogger.comtag:blogger.com,1999:blog-2267747408703654731.post-74448573891802749282010-08-01T13:18:07.438-07:002010-08-01T13:18:07.438-07:00Isn't time important for animations?Isn't time important for animations?Anonymousnoreply@blogger.com