LECTURE: LanguagE ComposiTion UnifiEd

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

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.