我也有牛津大学的数学学位！我花了一段时间才“拿到”新藏品。但我现在非常喜欢它。事实上，“map”的键入是2.7中最早让我感到困扰的事情之一（也许是因为我做的第一件事是集合类的子类之一）。

阅读Martin关于新的2.8集合的论文确实有助于解释隐式的用法，但是的，文档本身肯定需要更好地解释不同类型的隐式在核心API的方法签名中的作用。

我最担心的是：2.8将于何时发布？bug报告什么时候停止出现？scala团队是不是用2.8咬得太多了/试图一下子改变太多了？

我真的很希望在添加任何其他新功能之前，将2.8稳定发布作为一个优先事项，并想知道（在观望的同时）是否可以对scala编译器的开发路线图进行一些改进。

不幸的是，您提供的地图签名对地图来说是不正确的，而且确实存在合理的批评。

第一个批评是，通过颠覆地图的签名，我们得到了更一般的东西。认为这是一种默认的美德是一种常见的错误。它不是。映射函数被很好地定义为一个协变函子Fx->（x->y）->Fy，它遵循复合和恒等两个定律。任何其他归因于“地图”的东西都是一个笑话。

给定的签名是其他东西，但它不是地图。我怀疑它试图成为一个专门的、略有改动的“遍历”签名版本，该签名来自论文《迭代器模式的本质》。以下是其签名：

traverse :: (Traversable t, Applicative f) => (a -> f b) -> t a -> f (t b)

我将把它转换成Scala：

def traverse[A, B](f: A => F[B], a: T[A])(implicit t: Traversable[T], ap: Applicative[F]): F[T[B]

当然，它失败了——它还不够普遍！此外，它略有不同（请注意，您可以通过运行遍历Identity函子来获得map）。然而，我怀疑，如果库编写者更了解有充分记录的库概括（前面提到的是使用效果的应用编程），那么我们就不会看到这个错误。

第二，map函数在Scala中是一种特殊的情况，因为它用于理解。不幸的是，这意味着一个装备更好的库设计者不能忽视这个错误，而不牺牲理解的语法糖。换句话说，如果Scala库设计者要破坏一个方法，那么这很容易被忽略，但请不要映射！

我希望有人对此直言不讳，因为事实上，解决Scala坚持犯的错误将变得更加困难，显然是出于我强烈反对的原因。也就是说，解决“来自普通程序员的不负责任的反对（即太难了！）”的方法不是“安抚他们，让他们更容易”，而是，为成为更好的程序员提供指导和帮助。我和Scala的目标在这个问题上存在争议，但回到你的观点。

你可能是在表明自己的观点，预测“普通程序员”的具体反应。也就是说，那些声称“但这太复杂了！”或诸如此类的人。这些是你所指的耶格人或布洛赫人。我对这些反智主义/实用主义运动的人的反应相当严厉，我已经预料到会有一连串的反应，所以我将省略它。

我真的希望Scala库能够改进，或者至少可以将错误安全地隐藏在角落里。Java是一种“尝试做任何有用的事情”的代价非常高昂的语言，因此通常不值得这样做，因为大量的错误根本无法避免。我恳求斯卡拉不要重蹈覆辙。

我认为该方法的主要问题是（隐式bf:CanBuildFrom[Rrep，B，that]）没有任何解释。尽管我知道什么是隐式参数，但没有任何信息表明这会如何影响调用。浏览scaladoc只会让我更加困惑（很少有与CanBuildFrom相关的类甚至有文档）。

我认为一个简单的“bf的作用域中必须有一个隐式对象，它为B类型的对象提供了一个构建器”会有所帮助，但当您真正想做的是将a映射到B时，这是一个令人兴奋的概念。事实上，我不确定这是对的，因为我不知道Repr类型是什么意思，而Traversable的文档也毫无头绪。

所以，我有两个选择，都不令人满意：

假设它只适用于旧地图的工作方式以及地图在大多数其他语言中的工作方式深入了解源代码

我认为Scala本质上是在揭示这些东西是如何工作的，最终这是提供了一种实现oxbow_lakes所描述的方法。但签名会分散注意力。

嗯，我可以理解你的痛苦，但坦率地说，像你和我这样的人——或者几乎任何一个普通的StackOverflow用户——都不是规则。

我的意思是。。。大多数程序员都不会在意类型签名，因为他们永远不会看到它们！他们不阅读文档。

只要他们看到了代码如何工作的一些示例，并且代码不会使他们无法产生他们期望的结果，他们就永远不会查看文档。当失败时，他们将查看文档并期望在顶部看到用法示例。

考虑到这些，我认为：

任何人（像大多数人一样）遇到这种类型签名时，如果事先对Scala进行了处理，就会对其进行无限的嘲笑，如果他们喜欢Scala，就会认为它是Scala力量的象征。如果文档没有得到增强以提供使用示例，并清楚地解释方法的用途和使用方法，那么可能会有点影响Scala的采用。从长远来看，这无关紧要。Scala可以做这样的事情，这将使为Scala编写的库更加强大，使用起来更加安全。这些库和框架将吸引熟悉强大工具的程序员。喜欢简单和直接的程序员将继续使用PHP或类似的语言。

唉，Java程序员非常热衷于强大的工具，所以，在回答这个问题时，我刚刚修正了我对主流Scala采用的期望。我毫不怀疑Scala会成为主流语言。不是C主流，但可能是Perl主流或PHP主流。

说到Java，您曾经替换过类加载器吗？你有没有调查过这涉及到什么？如果你看看框架编写者所做的事情，Java可能会很可怕。只是大多数人都不知道。这同样适用于Scala，IMHO，但早期采用者倾向于在他们遇到的每一块岩石下寻找，看看是否有什么隐藏在那里。

我没有博士学位，也没有任何其他学位，既没有计算机科学，也没有数学，也没有其他领域。我以前没有使用Scala或任何其他类似语言的经验。我甚至没有使用远程可比类型系统的经验。事实上，我所掌握的不仅仅是表面知识，甚至还有一种类型系统的语言是Pascal，它并不完全以其复杂的类型系统而闻名。（虽然它确实有范围类型，而AFAIK几乎没有其他语言有，但这在这里并不重要。）我知道的其他三种语言是BASIC、Smalltalk和Ruby，它们都没有类型系统。

然而，我完全不难理解你发布的地图函数的签名。在我看来，这与地图上我见过的其他语言的签名几乎相同。不同的是，这个版本更通用。它看起来更像C++STL，而不是Haskell。特别是，它通过仅要求参数为IterableLike来抽象具体的集合类型，并且通过仅要求存在隐式转换函数来抽象具体返回类型，该函数可以从结果值集合中构建一些东西。是的，这很复杂，但它实际上只是泛型编程的一般范式的一种表达：不要假设任何实际上不需要的东西。

在这种情况下，map实际上不需要集合是列表，也不需要被排序或可排序等。地图唯一关心的是，它可以一个接一个地访问集合的所有元素，但没有特定的顺序。它不需要知道生成的集合是什么，只需要知道如何构建它。因此，这就是它的类型签名所要求的。

所以

map :: (a → b) → [a] → [b]

这是映射的传统类型签名，它一般不需要具体的List，而只需要IterableLike数据结构

map :: (IterableLike i, IterableLike j) ⇒ (a → b) → i → j

然后通过仅要求存在能够将结果转换为用户想要的任何数据结构的函数来进一步概括：

map :: IterableLike i ⇒ (a → b) → i → ([b] → c) → c

我承认语法有点笨拙，但语义是一样的。基本上，它从

def map[B](f: (A) ⇒ B): List[B]

这是地图的传统签名。（注意，由于Scala的面向对象特性，输入列表参数是如何消失的，因为它现在是单个分派OO系统中每个方法都具有的隐式接收器参数。）

def map[B](f: (A) ⇒ B): IterableLike[B]

现在，它用一个函数替换了IterableLike结果集合，这个函数实际上可以产生任何东西。

def map[B, That](f: A ⇒ B)(implicit bf: CanBuildFrom[Repr, B, That]): That

我真的相信这并不难理解。你只需要几个智能工具：

你需要知道（大致）map是什么。我承认，如果你只给出了类型签名，而没有给出方法的名称，那么很难弄清楚到底发生了什么。但既然你已经知道map应该做什么，而且你知道它的类型签名应该是什么，你就可以快速扫描签名并关注异常情况，比如“为什么这个映射将两个函数作为参数，而不是一个？”您需要能够实际读取类型签名。但是，即使您以前从未见过Scala，这也应该很容易，因为它实际上是您从其他语言中已经知道的类型语法的混合：VB.NET使用方括号来表示参数多态性，使用箭头表示返回类型，使用冒号来分隔名称和类型，这实际上是一种规范。您需要大致了解泛型编程是什么。（这并不难理解，因为它基本上都是用名称拼写的：它实际上只是以通用方式编程）。

这三项都不应该让任何专业程序员甚至业余程序员头疼。在过去的50年中，map已经成为几乎每一种语言的标准功能，不同的语言都有不同的语法，这一事实对于任何使用HTML和CSS设计网站的人来说都是显而易见的，如果没有一些来自圣教堂的讨厌的C++粉丝，你就无法订阅甚至远程编程相关的邮件列表。Stepanov解释泛型编程的优点。

是的，Scala很复杂。是的，Scala是人类所知的最复杂的类型系统之一，可以媲美甚至超越Haskell、Miranda、Clean或Cyclone等语言。但如果复杂性是一种编程语言成功的理由，C++早就死了，我们都会写Scheme。Scala很可能不会成功的原因有很多，但程序员在坐在键盘前不必费心动脑这一事实可能不是主要原因。

我是一个Scala初学者，老实说，我看不出那种类型签名有什么问题。参数是要映射的函数，隐式参数是生成器返回正确集合的参数。清晰易读。

事实上，整件事很优雅。生成器类型参数允许编译器选择正确的返回类型，而隐式参数机制对类用户隐藏此额外参数。我试过了：

Map(1 -> "a", 2 -> "b").map((t) => (t._2) -> (t._1)) // returns Map("a" -> 1, "b" -> 2)
Map(1 -> "a", 2 -> "b").map((t) =>  t._2)            // returns List("a", "b")

多态性做得很好。

当然，这不是一种主流范式，它会吓跑很多人。但是，它也会吸引许多看重其表现力和优雅的人。