使用过程计算和PL理论进行现代编程语言开发


10

一段时间以来,我对编程语言理论和过程计算非常感兴趣,并已开始对其进行研究。老实说,我不介意从事某种职业。我发现该理论令人着迷。我一直遇到的一个恒定问题是,PL理论或过程计算在现代编程语言开发中是否根本没有任何重要性。我在Pi演算上看到如此多的变体,并且有大量活跃的研究,但是它们是否会被需要或有重要的应用?我之所以这样问,是因为我喜欢开发编程语言,而真正的最终目标是使用该理论来实际构建PL。对于我写的东西,与理论之间确实没有任何关联。

Answers:


9

我的回答实际上只是对Gilles的阐述,在写我的著作之前我还没有读过。也许它还是有帮助的。

让我开始尝试通过区分编程语言工作的两个维度来回答您的问题,这两个方面在总体上与编程语言理论尤其是过程演算有很大不同。

  • 纯研究。

  • 以产品为中心的研发。

后者通常发生在工业中,目的是提供编程语言作为产品。Oracle的Java开发团队和Microsoft的C#开发团队就是例子。相反,纯粹的研究与产品无关。其目的是将编程语言理解为具有内在价值的对象,并探索所有编程语言所基于的数学结构。

由于目标各不相同,编程语言理论的不同方面与纯研究和以产品为中心的R&D有关。下图可能表明在哪里重要。

在此处输入图片说明

在这一点上,人们可能会问,这两个维度为何看似如此不同,以及它们之间的关系如何。

关键的见解是编程语言的研究与开发具有多个方面:技术,社会和经济。几乎按照定义,行业对编程语言的经济收益很感兴趣。Microsoft等人并不是出于内心的需要而开发语言,而是因为他们相信编程语言会给他们带来经济上的优势。他们已经深入研究了为什么某些编程语言成功,而其他似乎相似或具有更高级功能的语言却没有成功的原因。他们发现没有唯一的原因。编程语言及其环境很复杂,因此采用或忽略任何特定语言的原因也是如此。但是,编程语言成功的最大因素是程序员对已经被广泛使用的语言的优先依附:使用语言的人越多,可用的库,工具,教材越多,程序员的生产力就越高。可以使用该语言。这也称为网络效应。另一个原因是对于个人和组织而言,切换语言的成本很高:要掌握语言(尤其是对没有经验的程序员),并且在与熟悉语言的语义距离较大的情况下,要花费大量的时间。鉴于这些事实,人们可能会问,为什么新语言完全没有吸引力?公司为什么要完全开发新语言?我们为什么不只使用Java或Cobol?我认为,乳清语言的成功有几个关键原因,

  • 打开了一个新的编程领域,无需取代现有人员。主要的例子是伴随着Javascript兴起的网络。

  • 语言粘性。我的意思是改变语言的高昂代价。但是有时程序员会进入不同的领域,使用一种编程语言,并在新领域中成功使用旧语言。

  • 语言是由具有强大财务实力的大公司推动的。这种支持减少了采用的风险,因为早期采用者可以合理地确定几年后仍会支持该语言。C#是一个很好的例子。

  • 语言可能带有引人注目的工具和生态系统。这里也以C#及其.Net和Visual Studio生态系统为例。

  • 旧语言具有新功能。我想到了Java,它在每次迭代中都从函数式编程传统中汲取了更多的好主意。

  • 最后,一种新语言可能具有内在的技术优势,例如更具表现力,语法更好,键入系统会捕获更多错误等。

在这种背景下,纯编程语言研究与商业编程语言开发之间有些脱节并不令人惊讶。尽管两者都旨在提高软件的构建和开发效率,尤其是对于大型软件,但工业编程语言工作必须对促进快速采用以达到临界质量并获得网络效应更感兴趣。这导致对工作程序员关心的事情的研究集中。这往往是诸如库可用性,编译器速度,已编译代码的质量,可移植性等问题。我们今天实践的过程演算对从事主流项目的程序员几乎没有用(尽管我相信将来会改变)。

纯粹的编程语言研究是完全不同的。它可以与简化的编程语言模型一起使用: -calculus是函数式编程的极大简化。以同样的方式, -calculus是并发编程的极大简化。这些巨大的简化是成功研究的关键。它们使我们能够专注于核心计算机制(例如π βλπβ-用于功能编程的简化,用于逻辑编程的解析/统一,用于并行计算的名称传递)。要了解像Scala这样的语言是否可以进行可行的完整类型推断,我们无需担心JVM。确实,对JVM的思考将损害对类型推断的更好理解。这就是为什么将计算抽象为微小的核心结石至关重要而又强大的原因。

因此,您可以将编程语言研究视为一个巨大的沙盒,人们可以在其中玩玩具,如果他们在玩特定玩具时发现了一些有趣的东西,并且已经对玩具进行了彻底调查,那么该有趣的玩具便开始向主流工业接受迈进。我之所以说是长征,是因为编程语言研究人员首先发明的语言功能往往需要数十年才能被广泛接受。例如,垃圾收集是在1950年代构思的,并在1990年代随Java广泛使用。模式匹配可以追溯到1970年,仅从Scala开始被广泛使用。

过程演算是一个特别有趣的玩具。但这太新了,无法进行彻底调查。这将需要另外十年的纯粹研究。当前在过程理论研究中正在采取的是编程语言研究的最大成功案例,即(顺序)类型理论,并开发用于消息传递并发的类型理论。Hindley-Milner说,用于顺序编程的中等表现力的键入系统现在已经很好地理解了,无处不在,并且被工作的程序员所接受。我们希望为并行编程提供适度的表达类型。对此的研究始于1980年代,诸如米尔纳(Milner),桑吉欧基(Sangiorgi),特纳(Turner),小林制药(Kobayashi),本田(Honda)等开拓者,通常是基于线性逻辑的线性概念来进行明确或隐含的研究。在过去的几年中,活动量有了很大的增长,我预计这种上升趋势在可预见的未来还将继续。我还希望这项工作能开始渗透到以产品为中心的研发中,部分原因是出于实用性的原因,经过过程演算培训的年轻研究人员将前往工业研发实验室工作,而且还因为CPU和计算机体系结构的发展逐渐消失从顺序的计算形式。

总而言之,我不会担心您不会在您自己的构建语言工作中发现诸如过程演算之类的尖端编程语言理论。这仅仅是因为尖端理论不能解决当前编程语言的问题。这是关于未来的语言。“现实世界”需要一段时间才能赶上。您今天用来构建语言的知识是过去的编程语言理论。我鼓励您学习有关过程演算的更多信息,因为它是所有理论计算机科学中最退出的领域之一。


1
哇!制作该图表花了多少时间,将来我可以使用它吗?
科迪

1
@cody使用OmniGraffle花费了几秒钟,可以随时使用它。
Martin Berger 2014年

8

编程语言设计的科学还处于起步阶段。理论(对程序的含义以及语言的表达能力的研究)和经验主义(程序员要管理或不要做的事情)提供了许多定性的论据,以在设计语言时权衡一种或另一种方式。但是我们很少有定量的理由来决定。

在某种理论稳定到足以使一项创新可以在实际编程语言中使用的时间与该创新开始以“主流”语言出现之间的时间之间存在延迟。例如,可以说带有垃圾回收的自动内存管理在1960年代中期已经在工业上成熟,但是直到1995年才在Java中成为主流。参数多态性在1970年代后期得到了很好的理解,并使其成为现实。在200年代中期进入Java。从研究人员的职业规模来看,30年是很长的时间。

语言的大规模工业采用是社会学家研究的问题,而科学还处于起步阶段。市场因素是一个重要因素-如果Sun,Microsoft或Apple推广一种语言,则其影响要比任何数量的POPL和PLDI论文都要大。即使对于有选择权的程序员,库可用性通常也比语言设计重要得多。这并不是说语言设计并不重要:拥有精心设计的语言是一种解脱!通常这不是决定因素。

过程计算仍处于理论尚未稳定的阶段。我们相信我们了解顺序计算-我们喜欢称之为顺序计算的所有事物模型都是等效的(这就是Church-Turing的论点)。这并不适用于并发:不同的过程计算往往在表达能力上有细微的差异。

过程计算确实具有实际意义。那里分散了许多计算-它们涉及客户端与服务器对话,服务器与其他服务器对话等。甚至本地计算也经常是多线程的,以利用多个处理器上的并行性并对环境并发做出反应(与独立程序进行通信)以及与用户)。

为了开发更好的软件,是否需要进行研究?毕竟,那里有一个价值十亿美元的产业,无法从天空中的馅饼中分辨出pi演算。再说一次,该行业花费数十亿美元来修复错误。

在研究中,“将永远需要它们”从来都不是一个值得探讨的问题。不可能预先预测将产生长期后果。我什至会更进一步地说,这是一个安全的假设,即任何研究都将在一天后产生结果-我们当时不知道那一天是明年还是下一个千年。


3

我在Pi演算上看到如此多的变体,并且有大量活跃的研究,但是它们是否会被需要或有重要的应用?

我之所以这样问,是因为我喜欢开发编程语言,而真正的最终目标是使用该理论来实际构建PL。对于我写的东西,与理论之间确实没有任何关联。

这是一个棘手的问题!我将告诉您我的个人观点,并强调这是我的观点

我认为pi-calculus不适合直接用作并发编程的表示法。但是,我认为您绝对应该在设计并发编程语言之前对其进行研究。原因是pi演算给出了一个低级---但重要的是合成!---并发帐户。结果,它可以表达您想要的一切,但并不总是很方便。

解释此注释需要对类型进行一些思考。首先,有用的编程语言通常需要某种类型的规则才能构建抽象。特别是,在构建软件时,您需要某种函数类型来利用过程抽象。

现在,π演算的自然类型学科是经典线性逻辑的某种变体。例如,请参阅Abramsky的论文《过程可实现性》,其中显示了如何将简单的并发程序解释为线性逻辑的命题证明。(文献中包含许多有关键入pi-calculus程序的会话类型的工作,但是会话类型和线性类型非常相关。)

ABAB

从POV类型理论来看,这很好,但在编程时很尴尬。原因是程序员最终不仅要管理他们的函数调用,还要管理调用堆栈。(实际上,lambda演算到pi演算的编码通常看起来像是CPS转换。)现在,键入可以确保它们永远不会搞砸,但是尽管如此,程序员还是需要做很多记账工作。

这不是并发理论所独有的问题-mu演算很好地证明了诸如call / cc之类的顺序控制运算符的证明理论说明,但是是以使栈明确的代价为代价的,这使得它成为一种笨拙的编程语言。

因此,在设计并发编程语言时,我的观点是,您应使用比原始pi演算更高级别的抽象来设计语言,但应确保将其干净地转换为明智的类型化演算。(最近的一个很好的例子是Tonhino,Caires和Pfenning 的高阶过程,函数和会话:Monadic集成。)


从什么意义上讲,您需要在 -calculus中管理调用堆栈?这在米尔纳的编码为以及新的Van Bakel / Vigliotti编码中自​​动发生。函数是 -calculus 中语法糖的完美形式。λ π ππλππ
Martin Berger 2014年

同样, -calculus对诸如call / cc之类的顺序控制运算符确实很尴尬。这样的运算符更容易且自然地用 -caluclus 表示,因为跳转显然是消息传递的一种形式。 -calculus没有可以跳到的自然名称概念,因此您必须将其编码为funciton应用程序,或者必须添加其他内容。π λλμπλ
Martin Berger 2014年

关于功能的一种卓有成效的思考方式是它们是客户端-服务器交互,其中返回通道是仿射的,服务器通道是复制的。可以轻松键入。会话类型不能完全捕捉到这一点,因为它们在对交互的约束方面太弱了。
Martin Berger 2014年

所有这些,当然,与在原始 -calculus中相比,在原始 -calculus中进行编程当然是不希望的。两种形式主义都是简化,使我们能够专注于计算的某些特性,而其他特性则不然。λπλ
Martin Berger 2014年

@MartinBerger:我希望说服您回答!我的意思是,如果您想使用raw进行编程,并且还想使用函数,那么最终您将要写成米尔纳翻译图像中的术语,因此您必须“管理堆栈”从某种意义上说,您实际上是要管理连续性和显式替换。(顺便说一句,我不了解van Bakel / Vigliotti纸-谢谢!)π
Neel Krishnaswami

1

您说“ 真正的最终目标是使用理论来实际构建PL”。因此,您大概承认还有其他目标吗?

在我看来,理论的第一目的是提供理解,这可能是在推理现有的编程语言以及用它们编写的程序时。在业余时间里,我维护着一大批软件,一个电子邮件客户端,很久以前用Lisp编写。我所知道的所有PL理论,例如Hoare逻辑,分离逻辑,数据抽象,关系参数性和上下文对等等,在日常工作中都派上用场。例如,如果我要扩展软件的新功能,我知道它仍然必须保留原始功能,这意味着即使它要在Windows中做一些新的事情,它在所有旧环境下的行为也应相同。新环境。如果我对上下文等效一无所知,那么我可能甚至无法以这种方式来解决问题。

谈到有关pi演算的问题时,我认为pi演算还是有点太新了,无法在语言设计中找到应用。pi-calculus维基百科页面确实提到BPML和occam-pi作为使用pi-calculus的语言设计。但是,您可能还会看到其前身CCS的页面以及其他过程计算(例如CSP,join演算等)的页面,这些计算已在许多编程语言设计中使用。您还可以查看Sangiorgi and Walker书籍的“ Objects and pi-calculus”(对象和pi-演算)部分,以了解pi-演算与现有编程语言的关系。


By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.