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 <maxgol...@gmail.com > <javascript:>> 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 elm-discuss...@googlegroups.com <javascript:>. >> 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 elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
