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]}

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/" me…

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

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?

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 us…

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 funct…

Why functions cannot be part of Msg?

Learn

Josef-Vonasek May 5, 2018, 11:03am 6

Thanks Zoul,

that makes much more sense.

Consequences of functions in the model with 0.19?

Topic		Replies	Views
Implications of storing functions in model or msg type Learn	1	1459	April 8, 2020
Why not use: update fn state = fn state Learn	27	1750	March 5, 2021
[beginner] general msg/update Learn	6	1261	April 24, 2018
Message types carrying new state Learn	10	5166	October 13, 2018
Messages purpose Learn	9	1770	January 20, 2021

Why functions cannot be part of Msg?

Related topics