Elm - StartAppのタイプの問題

Question

Usersモジュールを（何も公開しないで）インポートするMainモジュールがあります。

app = 
    StartApp.start 
    { init = init 
    , inputs = [Signal.map TopBar topBarActionPort] 
    , update = update 
    , view = view 
    } 

しかしエルム原子炉が不平を言っていると意味がありませんUsersモジュールを使用しようとしている：

Mainでは、私はMainモジュールからの定義のみを使用して、にstartAppに通常の方法を使用しています。以下のメッセージを参照してください。

{ ... 
, inputs : List (Signal Users.Action) 
, update : Users.Action -> Model -> (Model, Effects Users.Action) 
, view : Address Users.Action -> Model -> Html 
} 

をしかし、それは次のとおりです：

機能startは、引数があることを期待している

{ ... 
, inputs : List (Signal Action) 
, update : Action -> Model -> (Model, Effects Action) 
, view : Address Action -> Model -> Html 
} 

は、どのようにそれがあるべきよう、コンパイラはMainモジュールの機能を利用するために？

Answer 1

これは、通常、「バブルアップ」するタイプ推論エラーがstartであることを示します。

型の注釈はElmでは必須ではなく、関数に型シグネチャを明示的に指定しないと、Elmはそれを推論します。簡単な例については

- 私はこの2つの関数だったとしますの名前は、それがリストを返すべきであることを示唆しているようだが、その戻り値の型に基づいて、エルムのようにコンパイル

getUsers = { name = "Bob", age = 42 } 

getUserNames = List.map .name getUsers -- compiler error! 

をList Userの代わりにUserと入力します。したがって、はちょうど良い（たとえ、のが予期しないタイプのシグネチャであるにもかかわらずコンパイルされます）。

しかし、が間違って定義されているという問題が発生したにもかかわらず、コンパイラは関数getUserNamesに何か問題があると伝えます。

このバブリング効果はおそらく、start機能を指している奇妙なコンパイラエラーが表示されている理由です。どの機能が正しくないかを追跡する方法は、すべてのモジュールにタイプ注釈を追加することです。

上記の簡単な例を考えてみましょう。関数に注釈を付けると、コンパイラは問題の根底にある関数について不平を言うでしょう。

getUsers : List User 
getUsers = { name = "Bob", age = 42 } -- compiler error! 

getUserNames : List String 
getUserNames = List.map .name getUsers 

エルムの型推論は、強力で非常に便利ですが、深くネストされた形で使用されている場合、それは時々奇妙と一見無関係コンパイルエラーを引き起こす可能性があります。私によく役立った経験則は、私のモジュールで公開されているすべての関数に注釈を付けることです。