Elmish.WPF type conflict: unit -> Model expected where Model provided?

Question

My Elmish.WPF app combines the Elmish.WPF Sample projects ‘NewWindow’ + ‘NewWindow.Core’ which I am adding to a copy of ‘FileDialogsCmdMsg’ + ‘FileDialogsCmdMsg.Core’.

FileDialogsCmdMsg is the basis of this effort and provides the background processing features to which I am adding the ‘NewWindow’ popup window features.

I am stuck on two (2) type-conflicts when WpfProgram.mkProgramWithCmdMsg is called...

...errors on update and bindings calls.

The compiler reports that line has the following errors (see red underlines above)...

...saying that WpfProgram.mkProgramWithCmdMsg expects a unit -> Model but was given a Model where update and bindings are called in the larger type specification.

But here is the type information for the calling function, WpfProgram.mkProgramWithCmdMsg accepting these parameters…

... sorry that is so large.

As you can see, both ‘update’ and ‘bindings’ are producing the Model parameter types expected by WpfProgram.mdProgramWithCmdMsg. And yet we have a unit->Model expected where a Model has been provided type-conflict; why?

Here is more detail on the update type-conflict…

... see how here how here it is claimed a unit->Model is expected when previously you see that update is supposed to expect a Model? Why?

You see the same problem in this detail on the type-conflict with ‘bindings’...

..again showing unit-Model' expected when the correct Model` type parameter is passed.

Here the type information where update is defined…

...and here is the bindings type info…

QUESTION: Why is a "unit->Model expected error reported when the receiving function, WpfProgram.mkProgramWithCmdMsg, and both parameters, update and bindings both respectively provide Model parameters?

Please ask if more detail is needed to get to the bottom of this.

Thanks for your help!

When working with Elmish.WPF and Bolero, I always nail down the signature of certain functions in order to avoid the chaos we see here. In that way I will not be lead astray when the type inference results in highly confusing and misleading information being given by the compiler. I suggest you explicitly declare types for arguments and return values of the functions init, update and bindings. Following that the compiler should be able to give you better advice. — Bent Tranberg, Oct 20 '22 at 10:17
You know, I suspected that was good practice but now I'll make that one the first tools when tackling this kind of mystery; thank you. BTW, @BentTranberg, another newbie Q why do you prefer Bolero over Fable or Giraffe? - RCHF — rfreytag, Oct 21 '22 at 01:24
Several historical and technical reasons, but it all boils down to Bolero being the easy alternative. I am not primarily a web developer, I work solo on a gargantuan project, and I can't cope with it all without simplicity. Same reasons I use F# and not C#. — Bent Tranberg, Oct 21 '22 at 04:51

Brian Berns · Accepted Answer · 2022-10-20T05:02:28.947

I suspect the problem is with your init function, which (I'm guessing) is a function of type unit -> Model. If this is true, the lambda fun _ -> init, [] binds the concrete type unit -> Model to the 'model type variable. As result, update and bindings also expect the same concrete type, leading to the error message you're seeing.

If I'm correct, you have two choices:

Change init so it is a value of type Model, rather than a function.
Change init so it also returns an empty message list, and then pass init directly to mkProgramWithCmdMsg, rather than passing a lambda.

Note that when you hover over mkProgramWithCmdMsg, the compiler shows you that 'model is indeed bound to unit -> Model, presumably due to the init type mismatch:

Thank you Brian. That was it. I totally missed the implications of my mis-definition of `init()` My solution now compiles and runs. — rfreytag, Oct 21 '22 at 01:22

Elmish.WPF type conflict: unit -> Model expected where Model provided?

1 Answers1