> > So the question is -- if you treat a TEA program as just a piece of data, > a four-piece record which does nothing (until you run it with > Html.program), can you define any standard operations which can take two > TEA programs and be guaranteed to give you another TEA program? If there > were such an operation that operation would be closed. In the mathematical > sense. I think what Peter D. was arguing for. >
I see. And this kind of thing is only possible if the functions for analyzing input and producing output are bound with the program state. On Tue, Sep 20, 2016 at 4:36 AM, Ambrose Laing <[email protected]> wrote: > I also understood "closure" as used by Abelson to mean closure in the > mathematical sense. The notion that if you apply a binary operation to two > items of one type, you get another item of the same type. I do see it as > being strongly related to the question of components or private state. > > In elm, we already have examples of closure in being able to combine > functions to obtain a larger function, combine records to obtain a larger > record, many Cmd msg to obtain another Cmd msg (using Cmd.batch), etc. > Abelson's example was one of combining two pieces of a rectangle type, to > obtain a larger rectangle. > > Right now consider what a TEA program is. One could argue that a TEA > program is in some sense a piece of data (it is a record with four standard > components called model, update, view and subscriptions, which must have > certain types). If you think of a TEA program this way, it is a piece of > data that does nothing (analogous to a binary executable). However if you > run the TEA program with Html.program or Html.programWithFlags, then it > becomes an interactive thing, that can pretend to a naive end-user that it > is stateful (analogous to a process). We could nit-pick and refine our > statement to further clarify that it is not in fact stateful in the sense > of being mutable, but rather uses immutability and that all the true > statefulness is managed for you by the elm framework. > > So the question is -- if you treat a TEA program as just a piece of data, > a four-piece record which does nothing (until you run it with > Html.program), can you define any standard operations which can take two > TEA programs and be guaranteed to give you another TEA program? If there > were such an operation that operation would be closed. In the mathematical > sense. I think what Peter D. was arguing for. > > > > On Tuesday, September 20, 2016 at 1:49:15 AM UTC-4, Nick H wrote: >> >> In the lecture Peter links to, the word "closure" is just being used to >> mean a function `a -> a`, where the return type matches the argument type. >> Like the mathematical sense of "the integers are closed with respect to >> addition." >> >> Its a useful property for a function to have, but in the sense used here, >> it's not really related to the question of components or private state. >> >> On Mon, Sep 19, 2016 at 10:34 PM, Max Goldstein <[email protected]> >> wrote: >> >>> Closure sounds like a nice property in theory. In practice, it's built >>> on the idea that you have to hide things, because things tend to break and >>> encapsulation is the only way to keep that breakage from spiraling out of >>> control. But in Elm, things don't break very often, and when they do the >>> compiler is there to catch them. So don't worry about components, just use >>> functions. >>> >>> That said, there's a very important point in OP about state for HTML >>> tags. For example, the reuse section of the guide has an example with >>> checkboxes. These boxes send messages to toggle their state when they are >>> clicked. But, there is no way to pre-populate the state of the checkboxes >>> for example with information you get from the server. In another thread, I >>> think this is worth discussing. If some HTML components are state full what >>> do we do about that, without jumping down the rabbit hole of components? >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Elm Discuss" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- > You received this message because you are subscribed to the Google Groups > "Elm Discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
