LECTURE: LanguagE ComposiTion UnifiEd

通用编程语言几乎是当前所有软件系统的基础。然而，大多数大问题不会自然地分解到任何一种编程语言的优点上。设想一个处理经济数据的政府部门。它的数据收集团队可能更喜欢使用Python；它的数据分析团队R；以及它的前端团队Java。然而，由于功能是混合的--例如，前端可能需要处理和分析数据--以这种方式使用不同的语言目前是不切实际的。相反，这类用户通常被迫选择一种语言，即使它不适合他们的大部分需求。语言合成是对这个长期存在的问题的一种解决方案：它旨在允许用户以细粒度的方式混合语言(编程语言和/或特定于领域的语言)，以便问题的每个部分都可以使用最适合它的语言来表达。然而，现有的语言合成方法往往要么是安全的，但在表现力方面受到限制(例如，Converge)，要么是灵活的但不安全的(例如，MetaBorg/Struco)。这种令人不快的选择在很大程度上是由于编程分为三个主要阶段造成的：编辑、编译和执行。每个阶段都有自己的工具(S)，迫使一种语言的语义在多个系统上复制。各种问题的结果是：工具之间的语言语义的差异或近似导致了细微的错误；工具之间的信息丢失阻碍了调试；编码导致了糟糕的性能。讲座研究员假设语言合成需要一个统一的工具环境，相当于编程语言IDE。这将把语言写作从将语言写作分散到多个不同的工具上而施加的许多实际负担中解放出来。我们将所需的工具称为“铸造厂”，即通过将新语言组合在一起来“铸造”新语言的环境；然后可以使用生成的语言来编写程序。Founddries将为最终用户提供一个单一的环境，允许他们编写语言，在结果中编写程序，将它们编译成合适的最终目标，执行和调试它们。因此，Founddries可以被认为是可定制的编辑器和编译器的组合，为最终用户提供一个单一的环境，允许他们编写语言，在结果中编写程序，将它们编译成合适的最终目标，执行和调试它们。最终，我们设想最终用户可以在不同的铸造厂中进行选择，就像他们可以在多种IDE中进行选择一样。一旦选择并下载了代工厂，用户将在已经实现的语言组件之间进行选择，以创建他们自己的合成语言。然后，他们将在当前的IDE中以尽可能自然的方式编辑程序。Tratt现有的语言合成研究--语言框使编辑合成的程序成为现实；而VM合成使运行合成的程序成为可能--提供了构建的支柱，但许多领域仍未解决，而Lecture本身就是针对这些领域展开的。需要将语言定义为一系列子组件(例如，语法、实现、类型定义)。语言内映射将把语法与实现联系起来。语言间映射将允许不同语言进行静态交互(例如，构建类型检查器)和动态交互(例如，交换运行时数据)。需要开发工具来表达其中的每一个，并以可理解的方式将结果呈现给用户。此外还有一些重要的设计问题：语言组件的合理粒度级别是多少？铸造厂如何才能得到最好的结构？等。

General purpose programming languages are the basis of virtually all current software systems. However, most large problems do not naturally decompose onto the strengths of any single programming language. Consider a government department processing economic data. Its data collection team might prefer to use Python; its data analysis team R; and its front-end team Java. However, since functionality is intermingled -- the front-end may need to both process and analyse data, for example -- it is currently impractical to use different languages in such a way. Instead, such users are typically forced to pick a single language, even though it is inappropriate for much of what they need.Language composition is one answer to this long-standing problem: it aims to allow users to mix languages (programming languages and / or domain specific languages) in a fine-grained manner, so that each part of a problem can be expressed using the language most suited to it. However, existing language composition approaches tend either to be safe but limited in expressivity (e.g. Converge) or flexible but unsafe (e.g. MetaBorg/Stratego). This unpalatable choice is in no small part caused by the division of programming into three main phases: editing, compilation, and execution. Each phase has its own tool(s), forcing a language's semantics to be duplicated over multiple systems. Various problems result: discrepancies, or approximations, of language semantics amongst tools cause subtle bugs; information loss between tools stymies debugging; and encodings lead to poor performance.The Lecture fellowship hypothesises that language composition needs a unified tool environment, equivalent to programming language IDEs. This will free language composition from the many practical burdens imposed by spreading language composition over multiple, distinct tools. We call the tooling required a "foundry", an environment for new languages to be "cast" by composing languages together; the resultant languages can then be used to write programs. Foundries will provide a single environment to end-users that will allow them to compose languages, write programs in the result, compile them into a suitable end target, execute, and debug them. Foundries can therefore be thought of as a combination of a customisable editor and compiler, providing a single environment to end-users that will allow them to compose languages, write programs in the result, compile them into a suitable end target, execute, and debug them. Ultimately, we envisage end-users choosing amongst different foundries in the same way that they can choose amongst multiple IDEs. Once a foundry has been chosen and downloaded, the user will then select between already implemented language components to create their own composed language. They will then edit programs in as natural a fashion as they can in current IDEs. Tratt's existing language composition research -- language boxes make editing composed programs a reality; and VM composition makes running composed programs feasible -- provides pillars upon which to build, but many areas remain untackled and it is to those that Lecture addresses itself. Languages will need to be defined as a series of sub-components (e.g. syntax, implementation, type definitions). Intra-language mappings will relate syntax to implementations. Inter-language mappings will allow different languages to interact statically (e.g. to build type checkers) and dynamically (e.g. to exchange run-time data). Tooling will need to be developed to express each of these and to present the result to users in a comprehensible fashion. Alongside these are important design issues: what are sensible granularity levels for language components? how can foundries be best structured? etc.