为什么要为在另一个模块中以相同方式定义的类型`type alias`？

Question

例如，从 任务模块中的任务类型的文档中可以看到：

type alias Task err ok =
  Task err ok

或者来自源代码：

type alias Task x a =
  Platform.Task x a

我认为答案是使其可以从定义的模块中自行公开。这正确吗？

---

更新：
Chad Gilbert提出了一个很好的观点，提到平台原语，如Task和ProcessId类型，它们的构造函数从未在那里使用过，但这就解释了为什么它们会被分组在这样一个中心位置。尽管他的答案没有解释为什么它们在各自的模块中被别名（参见Process.Id和Task.Task上面）。

我猜想，如果没有别名，任何试图使用模块Task和Process的人都必须导入这些特定类型（即Platform.Task，Platform.ProcessId），因为它们不是默认导入的（请参见Elm的默认导入）。

---

更新2：
另一个例子是模块Json.Decode module中的Value：

-- From the docs:
type alias Value = 
    Value

-- From the source:
type alias Value = JsEncode.Value

我认为这证明了我之前的假设，但我不愿回答我的问题，因为我是 Elm 的新手，很容易出错。

- toraritte

Answer 1

从Platform.Task的文档中可以了解到：

请参阅Task模块的文档，以获取更多信息。这里只定义了它，因为它是平台基元。

在这里它被定义为：

type Task err ok = Task

...这并没有告诉我们太多信息。Task是一个不透明的类型，它的内部Task构造函数从未被使用。它是Elm架构中的基本原语之一，并且根据上面的注释，似乎只在Platform中定义，因为它是平台中心原语的方便组合。

- Chad Gilbert

---

感谢您提到 Platform.Task，我应该在我的问题中加入它，但我试图理解在 Task 模块中将其定义为 type alias 的意义。我猜所有的原始类型都在 Platform 中定义，并且在它们自己的模块中被别名化，这样就不必通过它们的全名来引用它们，而可以通过它们的模块导出它们。（同样适用于 Platform.ProcessId 和 Process 中的 Id 类型别名）。 - toraritte

Answer 2

简而言之，我认为您这样做是因为您希望界面的结构与实现的组织方式不同。

您可以出于以下几个原因之一这样做：

1. 您希望从多个模块中公开相同的类型，因为对于包的使用者来说这样更有意义。同时，从工程角度来看，只需要一个实现就足够了（例如 Json.Encode/Decode.Value 的情况）。

2. 您的类型本身是不透明的（即构造函数未公开），您只需要它或希望它在不同于导入位置的地方定义。 我认为这是 Platform.Task 的情况：Evan 显然希望将所有平台原语组织在一个文件中。但是，从使用者的角度来看，导入一个 Platform.elm 会感觉很奇怪。这会让库的使用者感觉像是暴露了实现细节。

- Gabor