>
> 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 <akla...@gmail.com> 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 <maxgol...@gmail.com>
>> 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.
>>> 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.
>

-- 
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.

Reply via email to