-type queue(Type) :: {fifo, list(Type), list(Type)}.
您可能希望将其表示为:
-type queue(term()) :: {fifo, [term()], [term()]}.
这并不意味着这些是一致的术语。 term() 是 any() 的别名,仅表示“您有一个事物列表”,而不是“同质事物列表”。
这里更重要的问题是问你想做什么?您要达到的总体效果是什么? Erlang 标准库有大量的数据结构,可以非常有效地处理队列、包、集合、集合、地图、树等。
当然,您有特定需求的情况是您自己编写的。每次您有特定需求时,您都会发现自己需要全开放类型(如term())或严格类型(如non_neg_integer() 或#{integer() := pid()})。
如果我们对您想要达到的整体效果有更多了解,那么就有可能避免花费大量精力重新发明 OTP 或 stdlib。
关于 Erlang 的哲学
请记住,Erlang 不是一门学术语言。它是一种实用的工业语言,在学术概念方面受到影响,因为它们是有效语言和系统设计的自然结果——在它被创建的时代。
它是:
-
函数式 -- 但这只是因为在编写大量并发且不可能使用共享状态 OOP 进行推理的实际程序时,这是保持头脑清醒的最有效方式。李>
-
坚持“演员模型”——但早于该术语,因此不能说是“它的实现”。它看起来像一个演员模型,因为这是对大规模并发系统进行建模并表示进程之间清晰分区的唯一合理方法。
-
Reactive -- 但也早于该术语(作为流行词应用于软件)。这是使用消息传递模型的偶然结果。
-
有一个类型系统——但后来成长为函数式语言的积极副作用。但它不是一种“纯”函数式语言,因为副作用是用它编写的大多数程序的重点,并且类型系统必须是弱因为运行时的方式处理动态调用和生成等等。
(顺便说一句,您可能想到的大多数其他热门流行语也恰好描述了 Erlang,但这再次只是偶然的。Erlang 恰好完全符合流行语,并且可能会持续几十年。)
这意味着 Dialyzer 是一个允许的 类型器,而不是一个严格 类型器——它假定类型正确,直到它可以证明不是这样。严格的类型器则相反,假设类型错误,除非它可以证明或推断出其他方式。所以没有多态类型,因为程序中的所有内容都被假定为多态的,直到类型约束可以通过分析推断出或通过类型语言显式。例如,你不会在 Erlang 类型系统中发现像在 Haskell 中那样强大的功能——但你会发现整个系统都是专门为将现实世界的程序推出而设计的,尽管你在开发中的心态可能是有点不同。
另请参阅:dialyzer not detecting guard violation when function is exported