oxb*_*kes 865 scala scala-2.8 scala-collections
我刚刚开始研究即将发布的2.8版本中的Scala集合库重新实现.熟悉2.7中的库的人会注意到,从使用角度来看,库几乎没有变化.例如...
> List("Paris", "London").map(_.length)
res0: List[Int] List(5, 6)
......适用于任何一个版本.图书馆非常实用:实际上它太棒了.然而,那些以前不熟悉Scala并且想要了解语言的人现在必须理解方法签名,例如:
def map[B, That](f: A => B)(implicit bf: CanBuildFrom[Repr, B, That]): That
对于这样简单的功能,这是一个令人生畏的签名,我发现自己很难理解.并不是说我认为Scala有可能成为下一个Java(或/ C/C++/C#) - 我不相信它的创建者会瞄准那个市场 - 但我认为Scala成为/当然是可行的下一个Ruby或Python(即获得重要的商业用户群)
Steve Yegge 曾经因为他过于复杂的类型系统而攻击Scala(在我看来是错误的).我担心有人会在这个API上传播FUD(类似于Josh Bloch如何通过向Java添加闭包来吓唬JCP).
注意 - 我应该清楚,虽然我相信约书亚布洛赫在拒绝BGGA关闭提案方面具有影响力,但我并没有将此归因于他诚实地认为提案代表错误的其他信息.
尽管我的妻子和同事一直在告诉我,我不认为我是一个白痴:我在牛津大学获得了很好的数学学位,而且我已经在商业方面进行了近12年的编程,并在斯卡拉进行了大约一年(也是商业上).
请注意,炎症主题标题是关于 20世纪80年代早期英国政党宣言的引文.这个问题是主观的,但这是一个真实的问题,我已经成为CW,我想就此事提出一些意见.
Mar*_*sky 883
我希望这不是"遗书",但我能看出你的观点.你同时发现了Scala的优势和问题:它的可扩展性.这使我们可以实现库中的大多数主要功能.在其他一些语言中,序列中包含类似内容map或collect将内置的内容,并且没有人必须查看编译器必须经历的所有箍以使它们顺利运行.在Scala中,它都在一个库中,因此是公开的.
事实上map,其复杂类型支持的功能非常先进.考虑一下:
scala> import collection.immutable.BitSet
import collection.immutable.BitSet
scala> val bits = BitSet(1, 2, 3)
bits: scala.collection.immutable.BitSet = BitSet(1, 2, 3)
scala> val shifted = bits map { _ + 1 }
shifted: scala.collection.immutable.BitSet = BitSet(2, 3, 4)
scala> val displayed = bits map { _.toString + "!" }
displayed: scala.collection.immutable.Set[java.lang.String] = Set(1!, 2!, 3!)
了解如何始终获得最佳类型？如果你将Ints 映射到Ints再次得到一个BitSet,但是如果你将Ints 映射到Strings,你会得到一个将军Set.map的结果的静态类型和运行时表示都取决于传递给它的函数的结果类型.即使该集合为空,这也有效,因此该函数永远不会应用!据我所知,没有其他具有同等功能的集合框架.然而,从用户的角度来看,事情应该是如何运作的.
我们遇到的问题是,所有使这种情况发生的聪明技术都会泄漏到类型签名中,这些签名变得庞大而可怕.但也许用户不应该默认显示完整的类型签名map？怎么样,如果她抬起头,map在BitSet她的了:
map(f: Int => Int): BitSet (click here for more general type)
文档不会出现在这种情况下,因为从用户的角度来看,map确实具有类型(Int => Int) => BitSet.但map也有一个更通用的类型,可以通过点击另一个链接进行检查.
我们尚未在我们的工具中实现这样的功能.但我相信我们需要做到这一点,以避免吓跑人们并提供更多有用的信息.有了这样的工具,希望智能框架和图书馆不会成为自杀笔记.
Jör*_*tag 226
我没有博士学位,也没有任何其他类型的学位,既不是CS,也不是数学,也不是其他任何领域.我之前没有使用Scala或任何其他类似语言的经验.我甚至没有远程可比类型系统的经验.事实上,我所拥有的唯一一种语言,不仅仅是一种肤浅的知识,甚至还有一个类型系统,它是Pascal,并不完全以其复杂的类型系统而闻名.(虽然它确实有范围类型,AFAIK几乎没有其他语言,但这在这里并不真正相关.)我知道的其他三种语言是BASIC,Smalltalk和Ruby,其中没有一种甚至都有类型系统.
然而,我毫不费力地理解map你发布的功能的签名.它在我看来与我map见过的其他语言几乎相同的签名.不同之处在于此版本更通用.比起Haskell,它看起来更像是一个C++ STL.特别是,它仅通过要求参数来抽象远离具体集合类型IterableLike,并且通过仅要求存在可以从该结果值集合构建某些内容的隐式转换函数来抽象远离具体返回类型.是的,这是非常复杂的,但它实际上只是泛型编程的一般范式的表达:不要假设任何你实际上不需要的东西.
在这种情况下,map实际上并不需要将集合作为列表,或者被排序或可排序或类似的东西.唯一map关心的是它可以一个接一个地访问集合的所有元素,但没有特别的顺序.并且它不需要知道生成的集合是什么,它只需要知道如何构建它.所以,这就是它的类型签名所需要的.
所以,而不是
map :: (a ? b) ? [a] ? [b]
这是传统的类型签名map,它被概括为不需要具体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]
这是传统的签名map.(注意由于Scala的面向对象特性,输入列表参数消失了,因为它现在是单调度OO系统中每个方法都具有的隐式接收器参数.)然后它从具体List到一般化概括IterableLike
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是应该做的,你知道它的类型签名应该是,你可以快速扫描签名并专注于异常,像"为什么这map需要两个函数作为参数,不是吗？"这三者都不应该给任何专业甚至是业余爱好者的程序员带来严重的麻烦.map在过去50年中设计的几乎所有语言都是标准函数,不同语言具有不同语法的事实对任何使用HTML和CSS设计网站的人来说都是显而易见的,你不能订阅甚至远程编程相关的邮件列表没有来自圣斯捷潘诺夫教堂的一些恼人的C++粉丝,解释了泛型编程的优点.
是的,Scala 很复杂.是的,Scala拥有人类已知的最复杂的类型系统之一,可以与Haskell,Miranda,Clean或Cyclone等语言相媲美甚至超越.但是,如果复杂性是反对编程语言成功的一个论据,那么很久以前C++就会死掉,我们都会编写Scheme.Scala很可能不会成功的原因有很多,但程序员在坐在键盘前不能打开他们的大脑这一事实可能不会是主要原因.
sky*_*yde 175
C++中的相同之处:
template <template <class, class> class C,
class T,
class A,
class T_return,
class T_arg
>
C<T_return, typename A::rebind<T_return>::other>
map(C<T, A> &c,T_return(*func)(T_arg) )
{
C<T_return, typename A::rebind<T_return>::other> res;
for ( C<T,A>::iterator it=c.begin() ; it != c.end(); it++ ){
res.push_back(func(*it));
}
return res;
}
Dan*_*ral 71
好吧,我可以理解你的痛苦,但是,坦率地说,像你我这样的人 - 或几乎任何常规的Stack Overflow用户 - 都不是常规.
我的意思是......大多数程序员都不关心那种类型的签名,因为他们永远不会看到它们!他们不读文档.
只要他们看到代码如何工作的一些示例,并且代码不会在生成他们期望的结果时失败,他们就不会查看文档.当失败时,他们会查看文档并期望在顶部看到用法示例.
考虑到这些因素,我认为:
任何人(如在大多数人中)遇到过那种类型的签名都会模仿Scala,如果他们预先处理它,就会模仿Scala,如果他们喜欢Scala,它会认为它是Scala权力的象征.
如果没有增强文档来提供用法示例并清楚地解释方法的用途以及如何使用它,那么它可能会减少Scala的采用.
从长远来看,这无关紧要.Scala 可以做这样的事情会使为Scala编写的库更强大,更安全.这些库和框架将吸引程序员使用强大的工具.
喜欢简单性和直接性的程序员将继续使用PHP或类似语言.
唉,Java程序员很多都是电动工具,所以,在回答这个问题时,我刚刚修改了我对主流Scala采用的期望.毫无疑问,Scala将成为主流语言.不是C主流,但可能是Perl主流或PHP主流.
说到Java,你有没有替换类加载器？你有没有看过这涉及到什么？如果你看看框架编写者所做的那些,Java可能会很吓人.只是大多数人没有.同样的事情适用于Scala,恕我直言,但早期采用者倾向于在他们遇到的每一块岩石下面看,看看是否有隐藏在那里的东西.
Eri*_*cht 55
这会让人们去Scala吗？
是的,但它也会阻止人们被推迟.自从Scala获得对更高级别类型的支持以来,我一直认为缺少使用较高级别类型的集合是一个主要的弱点.它使API文档更复杂,但它确实使用更自然.
这是否会让scala在商业世界中成为一个不好的名字,作为一个只有专门的博士生可以理解的学术玩具？CTO和软件负责人是否会受到惊吓？
有些人可能会.我不认为许多"专业"开发人员可以访问Scala,部分原因是Scala的复杂性,部分原因是许多开发人员不愿意学习.雇用这些开发人员的首席技术官将被吓跑.
图书馆重新设计了一个明智的想法吗？
绝对.它使得集合与其他语言和类型系统相比更加合适,即使它仍然有一些粗糙的边缘.
如果你在商业上使用scala,你是否担心这个？您是打算立即采用2.8还是等待看看会发生什么？
我没有在商业上使用它.我可能要等到至少两次转入2.8.x系列之后才尝试引入它以便可以刷出错误.我还要等一下,看看EPFL在改进发展过程中取得多大成功.我所看到的看起来很有希望,但我为一家保守的公司工作.
一个更普遍的话题是"Scala对主流开发者来说太复杂了吗？"......
大多数主流或其他开发人员正在维护或扩展现有系统.这意味着他们使用的大部分内容都是由很久以前做出的决定决定的.还有很多人在写COBOL.
明天的主流开发人员将负责维护和扩展当前正在构建的应用程序.其中许多应用程序并非由主流开发人员构建.明天的主流开发人员将使用当今最成功的新应用程序开发人员使用的语言.
Car*_*icz 43
我有一个廉价的"大众市场"美国大学的本科学位,所以我说我落入了用户智能(或至少是教育)规模的中间:)我已经和Scala讨论了几个月并且已经开发了两三个非平凡的应用程序.
特别是现在IntelliJ已经发布了他们的精美IDE,其中恕我直言是目前最好的Scala插件,Scala开发相对无痛:
我发现我可以使用Scala作为"没有分号的Java",即我在Java中编写类似于代码的代码,并从语法简洁中获益,例如类型推断所获得的.异常处理,当我这样做时,更方便.没有getter/setter样板,类定义就不那么冗长了.
偶尔我会设法编写一行来完成相当于多行的Java.在适用的情况下,诸如地图,折叠,收集,过滤等功能方法的链条组成和优雅看起来很有趣.
我很少发现自己受益于Scala更强大的功能:闭包和部分(或咖喱)功能,模式匹配......这样的事情.
作为一个新手,我继续努力用简洁和惯用的语法.没有参数的方法调用不需要括号,除非他们这样做; match语句中的case需要一个胖箭头(=>),但也有一些你需要一个细箭头(->)的地方.许多方法都有简短但相当神秘的名称,/:或者\:- 如果我翻转足够的手册页,我可以完成我的工作,但我的一些代码最终看起来像Perl或线路噪音.具有讽刺意味的是,最流行的句法速记之一在行动中缺失:我一直被Int不定义++方法的事实所困扰.
这只是我的观点:我觉得Scala具有C++的强大功能以及C++的复杂性和可读性.语言的语法复杂性也使得API文档难以阅读.
斯卡拉在许多方面都经过深思熟虑和辉煌.我怀疑很多学者都喜欢在其中编程.然而,它也充满了聪明和陷阱,它具有比Java更高的学习曲线,并且更难阅读.如果我扫描论坛,看看有多少开发人员仍然在努力克服Java的细节,我无法想象Scala会成为主流语言.没有公司能够证明派遣开发人员参加为期3周的Scala课程,而之前他们只需要1周的Java课程.
dav*_*000 32
我认为该方法的主要问题在于(implicit bf : CanBuildFrom[Repr, B, That])没有任何解释.即使我知道隐含的参数是什么,但没有任何迹象表明这会如何影响调用.追逐scaladoc只会让我更加困惑(很少有与CanBuildFrom甚至有文档相关的类).
我认为一个简单的"必须有一个隐式对象在范围内为bf类型的对象提供构建器B到返回类型That"会有所帮助,但是当你真正想做的就是映射到的时候,这是一个令人兴奋的概念A.B的.事实上,我不确定这是对的,因为我不知道这种类型Repr意味着什么,而且文档Traversable肯定没有任何线索.
所以,我有两个选择,他们都不愉快:
我知道Scala本质上暴露了这些东西如何工作的内容,并且最终这提供了一种方法来执行oxbow_lakes所描述的内容.但这是签名中的分心.
小智 22
我是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")
这种多态性是正确的.
现在,被授予,它不是主流范式,它会吓跑很多人.但是,它也会吸引许多重视其表现力和优雅的人.
小智 20
不幸的是,你提供的地图签名对于地图来说是不正确的,并且确实存在合法的批评.
第一个批评是通过颠覆地图的签名,我们有一些更普遍的东西.认为默认情况下这是一种美德是一种常见的错误.事实并非如此.map函数被很好地定义为协变函子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]
当然它失败了 - 它不够通用!此外,它略有不同(请注意,您可以通过身份仿函数运行遍历来获取映射).但是,我怀疑如果库编写者更了解库文档的一般化,这些文章已经很好地记录了(应用程序编程与前面提到的效果),那么我们就不会看到这个错误了.
其次,map函数是Scala中的一个特例,因为它用于for-comprehension.不幸的是,这意味着装备更好的图书馆设计师不能忽视这个错误而不会牺牲理解的语法糖.换句话说,如果Scala库设计者要销毁一个方法,那么这很容易被忽略,但请不要映射!
我希望有人能够说出来,因为实际上,解决Scala坚持做出的错误会变得更加困难,显然是出于我强烈反对的原因.也就是说,"来自普通程序员的不负责任的反对意见(即太难了!)"的解决方案不是"安抚他们使他们更容易",而是提供指导和帮助以成为更好的程序员.我自己和斯卡拉的目标是在这个问题上争论,但回到你的观点.
您可能正在提出自己的观点,预测"普通程序员"的具体回答.也就是说,那些会声称"但太复杂了!"的人.或者其他一些.这些是你所指的Yegges或Blochs.我对反智主义/实用主义运动的这些人的回应非常苛刻,我已经预料到会有一连串的反应,所以我会省略它.
我真的希望Scala库可以改进,或者至少可以将错误安全地隐藏在角落里.Java是一种语言,"尝试做任何有用的事情"是如此昂贵,以至于它通常是不值得的,因为绝大多数错误都是无法避免的.我恳请斯卡拉不要走同样的道路.
Jam*_*han 15
我完全同意这个问题和马丁的回答:).即使在Java中,由于额外的噪声,使用泛型读取javadoc也比应该更难.这在Scala中是复杂的,其中隐含参数被用在问题的示例代码中(而implicits做非常有用的收集变形的东西).
我认为语言本身并不存在问题 - 我认为这更像是一个工具问题.虽然我同意JörgWMittag的观点,但我认为看看scaladoc(或IDE中某种类型的文档) - 它应该需要尽可能少的脑力来确定方法是什么,需要什么以及返回什么.没有必要在一点纸上破解一些代数来获得它:)
确定IDE需要一种很好的方式来显示任何变量/表达式/类型的所有方法(与Martin的示例一样,可以将所有泛型内联,因此它很好且易于理解).我也喜欢Martin默认隐藏隐含的想法.
以scaladoc为例...
def map[B, That](f: A => B)(implicit bf: CanBuildFrom[Repr, B, That]): That
在scaladoc中查看这个时,我希望默认隐藏通用块[B,That]以及隐含参数(如果你用鼠标悬停一个小图标,它们可能会显示) - 作为它的额外内容读它通常不相关.想象一下,如果这看起来像......
def map(f: A => B): That
它很好,清晰,明显.你可能想知道'那'是什么,如果你鼠标悬停或点击它可以扩展[B,那]文本突出显示'那',例如.
也许一个小图标可以用于[]声明和(隐式...)块,所以它清楚有一点声明崩溃了吗？它难以使用令牌,但我会使用.目前...
def map.(f: A => B).: That
因此,默认情况下,类型系统的'noise'隐藏在人们需要查看的主要80%的位置 - 方法名称,参数类型和返回类型,简单明了的方式 - 与细节的可扩展链接很少如果你真的那么在乎.
大多数人都在阅读scaladoc以找出他们可以在类型上调用的方法以及它们可以传递的参数.我们有点过多的细节权利淹没用户如何恕我直言.
这是另一个例子......
def orElse[A1 <: A, B1 >: B](that: PartialFunction[A1, B1]): PartialFunction[A1, B1]
现在如果我们隐藏泛型声明它更容易阅读
def orElse(that: PartialFunction[A1, B1]): PartialFunction[A1, B1]
然后,如果人们将鼠标悬停在A1上,我们可以显示A1的声明为A1 <:A.泛型中的协变和逆变类型也会增加很多噪声,这些噪声可以以更容易的方式呈现给用户.
and*_*oke 11
我不知道如何打破它,但我有剑桥博士学位,我使用2.8就好了.
更严重的是,我几乎没有花时间使用2.7(它不会与我正在使用的Java库交互)并且在一个多月前开始使用Scala.我有一些Haskell的经验(不多),但是忽略了你担心的东西,并寻找与我的Java经验相匹配的方法(我用它来谋生).
所以:我是一个"新用户"而且我没有被推迟 - 事实上它像Java一样让我有足够的信心忽略了我不理解的部分.
(但是,我看Scala的原因部分是为了看看它是否会推动它工作,我还没有这样做.让文档不那么令人生畏肯定会有所帮助,但令我惊讶的是它还有多少变化和发展(最公平的是我最让我感到惊讶的是它有多棒,但变化紧随其后).所以我想我所说的是我宁愿选择有限的资源来实现这一目标.最终状态 - 我认为他们很快就会期待这种流行.)
小智 10
根本不知道斯卡拉,但几周前我读不懂Clojure.现在我可以阅读其中的大部分内容,但除了最简单的例子之外,不能写任何东西.我怀疑斯卡拉没有什么不同.根据你的学习方式,你需要一本好的书或课程.光看地图上面的声明,我也许它的1/3.
我认为更大的问题不是这些语言的语法,而是采用并内化使它们可用于日常生产代码的范例.对我来说,Java并不是C++的巨大飞跃,这不是C的巨大飞跃,这不是Pascal,也不是Basic等的飞跃......但是像Clojure这样的函数式语言的编码是一个巨大的飞跃(对于我无论如何).我想在Scala中你可以用Java风格或Scala风格编写代码.但是在Clojure中,你会创造一些混乱,试图保持你的命令式习惯来自Java.
Scala有许多疯狂的功能(特别是在涉及隐式参数的地方),看起来非常复杂和学术,但旨在使事情易于使用.最有用的是获得语法糖([A <% B]这意味着类型A的对象具有对类型B的对象的隐式转换)以及他们所做的有充分记录的解释.但大多数情况下,作为这些库的客户端,您可以忽略隐式参数并信任它们做正确的事情.
这会让人们去Scala吗？
我不认为这是影响Scala流行程度的主要因素,因为Scala具有很强大的功能,并且它的语法不像Haskell,OCaml,SML,Lisps那样对Java/C++/PHP程序员来说是陌生的.等等..
但我确实认为Scala的受欢迎程度将低于今天的Java,因为我认为下一个主流语言必须大大简化,我认为实现这一目标的唯一方法是纯粹的不变性,即像HTML一样的声明,但图灵完成.然而,我有偏见是因为我正在开发这样一种语言,但我只是在排除了几个月的研究后才这样做,Scala不能满足我的需要.
这是否会让Scala在商业世界中成为一个不好的名字,作为学术玩具,只有专门的博士生才能理解？CTO和软件负责人是否会受到惊吓？
我不认为Scala的声誉会受到Haskell复杂性的影响.但我认为有些人会推迟学习它,因为对于大多数程序员来说,我还没有看到强制他们使用Scala的用例,他们会拖延学习它.也许高度可扩展的服务器端是最引人注目的用例.
而且,对于主流市场,首先学习Scala并不是一种"新鲜空气",人们会立即编写程序,例如首先使用HTML或Python.在得知所有从一开始就绊倒的细节之后,Scala往往会在你身上成长.但是,如果我从一开始就阅读Scala编程,我对学习曲线的经验和看法会有所不同.
图书馆重新设计了一个明智的想法吗？
当然.
如果您在商业上使用Scala,您是否担心这一点？您是打算立即采用2.8还是等待看看会发生什么？
我使用Scala作为我新语言的初始平台.如果我在商业上使用Scala,我可能不会在Scala的集合库上构建代码.我会创建自己的基于类别理论的库,因为我看过一次,我发现Scalaz的类型签名比Scala的集合库更加冗长和笨拙.部分问题可能是Scala实现类型类的方式,这是我创建自己的语言的一个小原因.
我决定写这个答案,因为我想强迫自己研究和比较Scala的集合类设计和我为我的语言所做的那个.不妨分享我的思考过程.
2.8 Scala集合使用构建器抽象是一种合理的设计原则.我想探讨下面的两个设计权衡.
只写代码:在写完这一部分之后,我读了Carl Smotricz的评论,该评论与我期望的权衡是一致的.James Strachan和davetron5000的评论一致认为,那个(它甚至不是那个[B])的含义和隐含的机制并不容易直观地掌握.在下面的问题#2中看到我对monoid的使用,我认为这更明确.Derek Mahar的评论是关于编写Scala的,但是阅读那些不是"在常见情况下"的其他人的Scala.
我读过有关Scala的一个批评是,编写它比阅读其他人编写的代码更容易.我发现这种情况偶尔会出于各种原因(例如编写函数的方法,自动闭包,DSL单元等),但如果这是主要因素,我还是未定.这里使用隐式函数参数有优缺点.从好的方面来说,它可以减少冗长并自动选择构建器对象.在Odersky的示例中,从BitSet(即Set [Int])到Set [String]的转换是隐式的.不熟悉的代码读者可能不知道集合的类型是什么,除非他们可以很好地推断当前包范围内可能存在的所有潜在的隐形构造候选者.当然,有经验的程序员和代码编写者会知道BitSet仅限于Int,因此String的映射必须转换为不同的集合类型.但是哪种收藏类型？它没有明确指定.
AD-HOC收藏设计:在写完这一部分之后,我阅读了Tony Morris的评论,并意识到我的观点几乎相同.也许我更详细的阐述会更清楚地说明这一点.
在"与类型的战斗位腐"Odersky&Moors中,提出了两个用例.它们是BitSet对Int元素的限制,Map是对元组元素的对,并且作为一般元素映射函数A => B必须能够构建备用目标集合类型的原因提供.然而,从类别理论的角度来看,这是有缺陷的.为了在类别理论中保持一致并因此避免极端情况,这些集合类型是仿函数,其中每个态射A => B必须映射在同一仿函数类别中的对象,List [A] => List [B],BitSet [A] => BitSet [B].例如,Option是一个仿函数,可以被视为一个Some(对象)和None的集合的集合.从Option's None或List's Nil到没有"空"状态的其他仿函数,没有一般的地图.
这里有一个权衡设计选择.在我的新语言的集合库的设计中,我选择将所有内容都变成一个函子,这意味着如果我实现了一个BitSet,它需要支持所有元素类型,通过使用非位字段内部表示来呈现非整数类型参数,该功能已在Scala中继承的Set中.我的设计中的Map只需映射其值,它可以提供一个单独的非functor方法来映射其(键,值)对元组.一个优点是每个仿函数通常也是一个应用程序,也许也是一个monad.因此,元素类型之间的所有函数,例如A => B => C => D => ...,被自动提升到提升的应用类型之间的函数,例如List [A] => List [B] => List [ C] => List [D] => ....对于从仿函数到另一个集合类的映射,我提供了一个map过载,它采用了一个monoid,例如Nil,None,0,"",Array()等.因此构建器抽象函数是monoid的append方法,并且显式地作为必要的输入参数提供,因此没有不可见的隐式转换.(Tangent:此输入参数还可以附加到非空幺半群,Scala的地图设计无法做到这一点.)此类转换是同一迭代过程中的映射和折叠.此外,我提供了一个可移动的,在类别意义上,"使用效果的应用程序编程"McBride和Patterson,它还可以在任何遍历到任何应用程序的单次迭代过程中实现map + fold,其中大多数集合类都是.状态monad也是一个应用程序,因此是任何可遍历的完全通用的构建器抽象.
因此,Scala集合是"ad-hoc"的,因为它不是基于范畴理论,而类别理论是更高层次指称语义的本质.虽然Scala的隐式构建器最初看起来比构造函数+ monoid builder + traversable"更普遍" - > applicative,但它们并未被证明与任何类别一致,因此我们不知道它们遵循什么规则.最一般的意义和角落案件将给予他们可能不遵守任何类别模型.添加更多变量使得更为通用的东西是不正确的,这是类别理论的巨大好处之一,它提供了维持一般性同时提升到更高级别语义的规则.集合是一个类别.
我读到某个地方,我认为是Odersky,作为库设计的另一个理由,是纯函数式编程具有有限递归和速度的成本,其中不使用尾递归.到目前为止我遇到的每一种情况都没有发现使用尾递归很困难.
另外,我在脑子里想到一个不完整的想法,Scala的一些权衡是由于试图成为一种可变和不可变的语言,不像Haskell或我正在开发的语言.这与托尼莫里斯关于理解的评论一致.在我的语言中,没有循环,也没有可变构造.我的语言将位于Scala之上(目前为止),并且很大程度上归功于它,如果Scala没有通用类型系统和可变性,这将是不可能的.虽然这可能不是真的,因为我认为Odersky&Moors("与类型斗争")不正确地指出Scala是唯一具有更高种类的OOP语言,因为我验证了(我自己和通过Bob Harper)标准ML有它们.同样出现SML的类型系统可能具有同等的灵活性(自20世纪80年代以来),这可能不容易理解,因为语法与Scala并没有那么类似于Java(和C++/PHP).无论如何,这不是对Scala的批评,而是试图对权衡进行不完整的分析,这是我希望与这个问题密切相关的.Scala和SML不会受到Haskell无法进行菱形多重继承的影响,这很关键,我理解为什么Haskell Prelude中的这么多函数会针对不同类型重复.
小智 5
这里似乎有必要说明学位:政治学学士学位和计算机科学学士学位.
要点:
这会让人们去Scala吗？
Scala很难,因为它的底层编程范例很难.功能编程让很多人感到害怕.可以在PHP中构建闭包,但人们很少这样做.所以不,不是这个签名,而是所有其他人都会放弃,如果他们没有特定的教育,使他们重视潜在范式的力量.
如果有这种教育,每个人都可以做到.去年我在斯卡拉与一群学校的孩子们一起制作了一台国际象棋电脑!他们有他们的问题,但他们最终做得很好.
如果您在商业上使用Scala,您是否担心这一点？您是打算立即采用2.8还是等待看看会发生什么？
我不担心.
| 归档时间： |
|
| 查看次数： |
112421 次 |
| 最近记录： |