Why functions cannot be part of Msg?

[Josef-Vonasek]

Why functions cannot be part of message?
Why not serialize them as javascript object {body: ..., args: [ ... ]}?

As an example (plus 77) will be serialized (in javascript) as {body: a => b => a + b, args: [77]}

[mfeineis]

Since Elm isn’t homoiconic like Lisp and because of a conscious choice by the creator messages are pure data.

What would you want that for in Elm? You can’t eval that. You chose a simple referentially transparent function without clojures… what happens to something like this?

endpoint = "/api/"
message =
    { callIt = \slug -> endpoint  ++ slug
    }

Do you serialize the whole program? Some part? What does that even mean? Do you restrict which functions can be serialized, wouldn’t that be annoying?

It’s complicated, I’d say. You could decide on some rule but to what end?

[Josef-Vonasek]

You evaluate endpoint and send {body: a => "/api/" ++ a, args: []}

[mfeineis]

This is just one way to do that in this instance, but the question stands: what do you want to do with a serialized function in Elm?

[zoul]

Generally speaking, in Elm you model an app with explicit state modified by a pure function based on messages with clear semantics. This makes it very easy to reason about the state changes: it’s quite obvious what state the app is in and what state transitions lead to this state.

Once you start using functions in messages, this model gets much more powerful, but much less transparent. You lose the clear distinction between data and code – the messages no longer describe what you want done, they implement a part of it. You cannot see the behaviour just by looking at the update function anymore. And comparing or serializing the messages gets more complicated.

In the end, it’s probably not worth it.

[Josef-Vonasek]

Thanks Zoul,

that makes much more sense.

[gampleman]

Note: functions can totally be a part of Msgs. It is simply not recommended (and not supported in the debugger).

Furthermore, you can sometimes struggle to tell the difference between the two. Since a package author can expose an opaque type, you have little way of knowing whether it contains functions, as that is an implementation detail of that type.

[system]

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.