T Hesa德博士学位L’UNIVERSITÉ DE RENNES和科尔 D八角形第601章数学与信息与通信科学与技术由皮埃尔·让让IDE即代码作为一等公民的强化语言协议论文于2022年4月29日在雷恩发表并答辩研究单位：Inria，IRISA，Equipe DiverSE答辩前的报告员：马克·范登布兰德埃因霍温理工大学教授理查德·佩奇麦克马斯特大学教授评审团组成：请注意，如果评审团主席：弗朗索瓦·泰亚尼教授雷恩第一检查员：塞巴斯蒂安·埃尔德韦格理查德·佩奇教授教授约翰内斯·古腾堡大学麦克马斯特大学Dir.论文：艾玛·索德伯格马克·范登布兰德伯努瓦·康贝马勒会议主持人教授隆德大学埃因霍温理工大学雷恩第一大学共同导演。论文：奥利维尔·巴拉斯教授雷恩第一一个知识渊博的人3虽然写一个确认部分并不是强制性的，但我仍然觉得有必要写一些个人笔记，最终接受我已经完成了我一直被告知"一个好的论文是一个完成的论文"，这可能听起来很愚蠢，但我无法强调这句话所带来的智慧3.5年，就是这么长时间随着全球大流行的爆发...是的，那很有趣。现在，我在这里，有一个完整的手稿，一个成功的辩护，一个博士学位，仍然有这么多的 这一切都有意义吗？ 冒名顶替者综合征是一种可怕的疾病，但我猜这也是博士生的但现在，论文终于完成了。一路上我可能有几次摔断了一匹马，但我又爬了起来，最终我吃了那匹马。所以，不管我现在怎么想，现在是时候接受这是一篇好论文了如果你，读者，是另一个博士生，在这些漫无边际的颠簸，我希望你也能在那里。无论如何，我真正需要感谢的第一个人是那些一直和我在一起的人：基本上是D IVER SE研究团队的每个人。老实说，我无法想象与任何其他团队达到这一点。非常感谢我的两位顾问Benoit Combemale教授和BenoitCombemale教授。Olivier Barais，给了我这个职位，并在整个任期内成为这样一个驱动力（尽管过于繁忙的时间表和多次停工）。感谢Didier、Manuel和Dorian的指导。 谢谢你格温达尔不断地打断我的工作，也管理防守。现在，我不会试图写一个详尽的名单，所有的成员，我满足，但感谢大家的良好情绪，支持，和所有有趣的想法诞生的咖啡休息。接下来，我需要感谢同意审阅本作品的评审团成员最后，你是那些使这成为可能的人，把这段时间变成了一篇好论文。我会考虑您的反馈，尽我所能采纳您的建议，总的来说，我非常喜欢与你们所有人交流更私人的是，我必须感谢我的朋友和家人。 谢谢妈妈和爸爸把我带到这里，毫无疑问，我会在某个时候到达那里。感谢朱莉和奥罗拉也相信，甚至协助辩护。4感谢Mimi和Fidji来到这里，尽管你可能不知道，但我真的需要包括你。我也感谢JAPAN7的每一个人，感谢他们的聪明，感谢他们不断地偷走我的注意力。你有很多想法，所以我甚至不会试着叫你的名字。来自T& E FRIENDS OF USUALLY（这不是错别字）的家伙们，我们也可以在这个时候放更多的东西，但我很高兴我们还没有完成如果你觉得你没有在这里被命名，但应该已经，嗯，对不起，但它实际上是很难写一个确认部分。每一个在某个时候帮助过我的人可能都值得在这里，但时间已经够长了。我只想用最后的感谢来结束这件非常俗气的事情：音乐一直是我生活中的一个主要部分，因此也是我工作中的一个主要部分，所以我想感谢我最喜欢的艺术家Haru Nemuri，在我最需要的时候给我带来了这么多的感觉。她统治。T ABLE来自C组5法文简介9上下文。... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...9问题陈述10捐款14实施和评估151导言171.1背景171.2问题陈述181.3捐款221.4执行情况评价231.5大纲241.6出版物清单241.6.1新闻出版物241.6.2正在进行的工作251.6.3其他252背景技术272.1综合发展环境272.2领域特定语言282.3软件语言中的可执行性302.4语言服务332.4.1语言工作台332.4.2IDE可移植性342.5REPL口译员352.6协议工程36内容表63IDE作为代码39的愿景3.1动机393.2指定语言协议403.3实施424REPL口译员的原则性方法4.1动机474.2REPL域分析494.3方法论524.3.1实用主义554.3.2通用REPL语言扩展564.4案例研究594.4.1MiniJava59的Jupyter笔记本4.4.2QL：用于问卷644.4.3eFLINT：可执行规范684.5讨论715从DSL规范到交互式计算机编程环境5.1动机755.2方法概述785.3技术细节和实施815.3.1DSL规范增强815.3.2抽象语法转换855.3.3具体语法转换865.3.4语义学变换875.3.5REPL接口和交互式环境示例5.4评估905.5第93章第一次见面6从语言运行时中分离执行服务的协议6.1动机976.2最低限度执行协议1006.2.1服务标识1006.2.2协议规范1026.3执行情况评价104T ABLE来自C组76.3.1操作语义学形式化1046.3.2语言实现111内容表6.4讨论1187结论展望1217.1结论1217.2前景122参考文献1259一、引言在FRancaise上下文L’ingénierie 集成开发环境（IDE）最初被设计为一种将给定语言的各种服务（例如，编辑、调试、验证、编译等服务）组合到单个软件中的方式。然而，我们看到越来越多的项目同时利用了多种编程语言的优势，无论是在孤立的部分（例如，在全栈开发中，还是在微服务架构中），甚至是在同一个代码库中，随着多语言开发的最新趋势。[37][80]因此，现在需要在为了避免为每个现有的IDE开发特定的语言服务，语言协议近年来已经成为语言工程社区感兴趣 通过使用明确定义的协议进行通信，核心语言服务可以在支持这些协议的各种IDE中重用。一个直接的后果是，为特定语言提供适当支持的责任不再由IDE制造商承担，而是由独立于任何特定平台开发服务的语言维护人员承担。第一个语言协议，即语言服务器协议（LSP）1，是由Microsoft在VS Code 2的开发过程中提出的。LSP的作用是通过提供符合开放和可自由搜索规范的语言服务器实现来支持任何语言的通用编辑服务它是围绕一组服务设计的1. cf.https://microsoft.github.io/language-server-protocol/2. cf. https://code.visualstudio.com/10内容表从最常用的通用语言的专用代码编辑器中提取LSP、调试适配器协议（DAP）3以及我们今天看到的大多数其他语言协议指定了在单个客户端（IDE的用户界面组件）和单个服务器（为客户端提供所有必要服务的后端）之间交换的数据的结构，以及可以从一个客户端发送到另一个客户端的请求和事件。大多数消息都包含在所谓的"功能"中所有功能都由协议规范定义和固定。问题陈述随着LSP和DAP的成功，我们看到新的语言协议出现在新的用例中（例如，构建服务器协议4或测试适配器协议5），并出现在现有协议不支持的特定功能中（例如，在图形语法的情况特别有趣，因为它导致了两种不同协议的定义：图形语言服务器协议6和图形服务器协议7。扩展LSP功能的另一种方法是在服务器和客户端上任意添加对新消息的支持，并假设所有现有的实现都将忽略它们，如果它们不支持的话。 虽然这两项工作都提供了非常有用的贡献，但这样的实现提出了可维护性和互操作性问题，这进一步推动了我们的工作。从长远来看，继续为每个用例创建独立的协议将适得其反，因为这将违背定义这些协议的目的，即：确保对不同用例的适当支持。3. cf. https://microsoft.github.io/debug-adapter-protocol/4. cf. https://build-server-protocol.github.io/5. cf.https://github.com/microsoft/vscode-debugadapter-node/issues/1546. cf. https://www.eclipse.org/glsp/7. cf. https://obeonetwork.github.io/GraphicalServerProtocol/内容表11在所有开发环境中提供服务在现实世界中，这将把挑战转移到现有协议的可组合性和兼容性上，而这些协议目前还没有得到解决。因此，我们正在探索将服务器分解为相互交互的各个服务的想法，而不是让服务器包含给定语言的所有服务。为了确保这些服务和客户端之间的通信，以及它们的编排，我们考虑了明确支持它们的所有交互所需的规范因此，我们设想定义一个语言元协议，从中我们可以导出最相关的实例化（即语言服务的配置），而不是从头开始定义一个语言协议，与特定的用例相关联。通过这种方法，现有协议中实际上是通用的部分可以被分离，并且它们的实现可以通过在多个服务配置中重用而得到更好的利用。 它还为整体体系结构带来了更大的灵活性：可以根据用例将专用服务移动到其他机器或替换，可以随时添加或删除功能，并且可以独立地精细控制每个服务的部署。 我们将这一愿景称为IDE即代码（或"可编程开发环境"）。如图1所示，我们希望语言设计者不仅提供他们的语言规范，而且提供关于不同服务所需的协议交互的信息。 从那里，我们可以得到"语言服务包"，它们是彼此交互的最小的、独立的语言服务。通过使用这些软件包，用户应该能够指定如何配置和部署他们的IDE（或使用预定义的IDE），以根据他们的工作环境和用例设置适合他们需要的开发环境开发人员需要最佳地访问语言服务，无论他们在哪里工作，也无论他们的设备如何随着COVID-19的大流行，越来越明显的是，并不总是能够确保获得稳定的工作环境，越来 越多的努力被 投入到基于云的IDE的开发中。https://ecdtools.eclipse.org/events/idesummit/2021/.虽然它们允许用户从任何地方访问持久的开发环境，但它们也有一些必须解决的缺陷。内容表12图1内容表13需要稳定和快速的互联网接入，这可能会在旅行、有限的定制和不足以同时为所有用户提供无缝体验的规模等情况下大幅诸如[25]之类的工作已经考虑到了这些限制，并且已经探索了将语言服务分离成微服务的想法，作为这些问题的解决方案，微服务具有本地或跨不同服务器的当涉及到支持不同的用例时，我们可以考虑，例如，习惯于通过图形语法使用专用语言的一些研究，如[69]认为，当他们的环境提供了太多的工具和服务时，专业人士经常会感到不知所措这可能会适得其反，因为当用户被不必要的功能淹没时，很难突出显示最有用的功能因此，这种方法的目标之一是为用户提供一个干净的、最小的环境，在这个环境中，他们只能访问他们实际使用的在开发环境中可以找到的组件 它们的范围可以从用于语言的文本语法的语法分析器到用于执行程序的调试器。在本文中，我们将重点放在运行时组件上，即在交互式环境的上下文中启用和指导程序执行的组件（例如，解释器或调试器）。在这方面，我们面临三个挑战：- 第一个问题直接涉及这些不同组件之间的通信方式。具有固定协议的简单客户端/服务器方法不足以支持这样的环境的定制。因此，有必要将语言协议作为第一类对象直接操作，就像实现它们的组件内容表14— 第二种方法是在不同的执行组件之间建立一个层次结构L’objectif principal estd’améliorer la réutilisation des implémentations de services, 这也意味着我们必须指定这些组件之间的依赖关系，并定义它们相互交互所需的协议。— 第三种方法是使用语言规范中已经存在的信息，并通过应用可能的生成过程，实际生成满足协议规范的语言组件贡献本文的主要贡献是IDE即代码的概念我们讨论了作为由于环境配置通过将语言协议作为第一类对象来操作，我们可以利用实现它们的服务的可重用性，甚至可以定义一个层次结构，其中特定的协议扩展或使用其他协议的组合当我们考虑到给定DSL可能需要的许多运行时工具，这一点尤其因此，本文的第二个贡献是定义了可以运行其他语言运行时工具的最基本组件在此组件之上，我们可以为每个已标识的执行模式提供通用执行工具。作为第三个贡献，我们描述了一种使用上述协议从专用语言规范创建REPL解释器的生成式方法8. cf. https://gitlab.com/gitlab-org/gitlab内容表15这允许实施和评估本文档中讨论的实现专门针对专用语言（DSL）。从现有的DSL规范中，我们提出了一种生成式方法来导出REPL解释器，这是一种能够增量执行部分程序的语言执行工具这样的解释器可以在诸如笔记本（例如Jupyter Notebook）之类的环境中使用，我们将其称为"交互式编程环境"。这些环境依赖于一个增量开发过程，在这个过程中，开发人员可以编写和记录小的、独立的代码片段并获得反馈，这混合了探索性编程[45]和知识编程[49]的方法。我们用于评估此实现的DSL也提供了高级调试功能然而，当我们试图将它们集成到这样的环境中时，我们注意到用于实现这些调试器的方法和我们的REPL解释器之间存在一些冲突。 在某些情况下，它们都提供相同的功能，而在其他情况下，它们相互阻碍。 这导致了运行时工具层次结构的定义，其中REPL解释器和调试器依赖于公开形式化操作语义的组件的单个实现。然后，我们推导出另一种方法来获得所述组件，或者由语言工程师每年实现，或者从现有的操作语义生成性地推导。然后，我们将其他运行时工具作为通用实现呈现，通过特定的语言协议与该组件交互。为了激发我们的愿景并评估我们的实现，我们在本文中考虑了一个交互式编程环境，它提供了从运行时跟踪进行全知调试的可能性，类似于[ 18 ]中提出的方法。为了向几个不同的平台提供全知调试器支持，我们实际上可以使用DAP，因为它指定了一个步骤-内容表16回来。然而，在[ 18 ]中引入的回溯机制提供了比简单回溯更多的控制：例如，可以决定在函数/方法内部或外部回溯目前，还没有语言协议支持这种粒度级别的回滚此外，生成和存储运行时跟踪是一个非常昂贵的过程，不应一直启用，最好理想情况下，它的启用应该在整个调试会话中是可控的17CHAPTER 1一、引言1.1上下文现代软件工程主要包括使用最适合任务的编程语言，这与有效使用这些语言的工具支持集成开发环境（IDE）最初被设计为在单个软件中聚集给定语言的各种服务（例如用于编辑、调试、检查、编译的设施）的方式。然而，我们倾向于看到越来越多的项目同时利用多种编程语言的优势，或者针对孤立的部分（例如，全栈开发，微服务架构）或甚至在与多语言开发的最新趋势相同的代码库中。[37][80] 因此，需要在相同的环境中访问多种语言的服务为了防止为每个现有IDE开发特定语言服务，语言协议近年来已经成为语言工程界感兴趣的话题（[21]，[65]，[68]）。通过通过定义良好的协议进行通信，主语言服务可以跨支持所述协议的各种IDE来使用。一个直接的后果是，为特定语言提供适当支持的责任不再是IDE制造商关心的问题，而是依赖于独立开发服务的语言维护者。第一个语言协议，称为语言服务器协议（LSP）1，是由微软在VS代码2开发的上下文中提出的。LSP的作用是支持提供符合给定开源规范的语言服务器实现的任何语言的公共编辑服务它是围绕一组服务设计的，这些服务是从最常用的通用语言的专业代码编辑器中提取的。因此，现在，任何代码编辑器都可以为具有LSP 实现的GPLs提供相同级别的语言支持，例如， VS代码和NeoVIM 3产品1. cf.https://microsoft.github.io/language-server-protocol/2. cf. https://code.visualstudio.com/3. cf. https://neovim.io18第1章相同的语法突出了Pyright4中Python程序的符号文档、类型检查和重构功能。LSP、调试适配器协议（DAP）5以及我们现在看到的大多数其他语言协议（例如， 图形语法、编译、测试）指定在单个客户端（IDE的UI组件）和单个服务器（提供客户端所需服务集的后端）之间交换的数据的结构，以及可以从一个发送到另一个的请求和事件。大多数消息都包含在"功能"中功能集由协议规范设置和固定其思想是，客户端和服务器都可以选择简单地执行功能的一个子集，并通知另一个子集，后者应该能够根据规范使用所有相应的消息1.2问题陈述在协议级别设置服务集意味着它可能不适合每个用例。例如，在考虑域特定语言（DSL）时，我们经常发现一些不寻常的特征，这些特征可能与用于设计语言的元语言方法有关（例如， 一般服务[17]）、语言本身（例如，范例、语法），或者甚至正在开发的程序（例如， 当前状态表示）。虽然我们可能会争辩说，将这些特征中的一些作为新功能添加到现有协议中是相关的，但在一个通用协议中涵盖所有特定用例是不可想象的。尽管如此，DSL的采用将从多个主要IDE的支持中受益匪浅，因为它们将更好地集成到用户的工作流中协议使这种情况成为可能，尽管一些功能会在过程中丢失。[21随着LSP和DAP的成功，我们看到针对这两种新用例出现了新的语言协议（例如， 构建服务器协议6、测试适配器协议7）和现有协议不支持的特定功能（例如在LSP中使用图形语法[68]）。图形语法的情况特别有趣，因为它导致了用于相同目的的两个不同协议的定义：图形语言服务器协议8。4. cf. https://github.com/microsoft/pyright5. cf. https://microsoft.github.io/debug-adapter-protocol/6. cf. https://build-server-protocol.github.io/7. cf.https://github.com/microsoft/vscode-debugadapter-node/issues/1548. cf. https://www.eclipse.org/glsp/1.2. 问题陈述19和图形服务器协议9。 扩展LSP功能的另一种方法是[60]和[50]任意地向服务器和客户端添加对新消息的支持，并假设所有现有的实现如果不支持它们，就会忽略它们。 虽然这两项工作都提供了非常有用的贡献，但这样的实现引起了对可维护性和互操作性的关注，这进一步激发了我们的工作。从长远来看，为每个用例保持独立的协议将适得其反，因为这将破坏定义这些协议的目的，即： 确保在所有开发环境中提供适当的支持。在现实世界中，这将改变对现有协议的可组合性和兼容性的挑战，而这些挑战目前尚未得到解决。Hence，而不是有一个服务器，涵盖了给定语言的所有服务，我们探讨了将其分解为与彼此交互的各个服务的想法。为了确保这些服务和客户端之间的通信，以及它们的编排，我们认为规范是明确要求的，以支持它们的所有交互。 因此，我们设想元语言协议的定义，而不是从基础定义语言协议，与特定的用例相关联，我们可以从该元语言协议导出最相关的实例化（即，语言服务配置）。通过这种方法，可以分离当前通用的现有协议的一些部分，并且通过在多个服务配置中使用它们的实现 这也为整体体系结构提供了更大的灵活性：专门的服务可以根据用例移动到其他机器或替换，功能可以随时添加或删除，并且可以独立地精细控制每个服务的部署。我们将此愿景称为IDE as Code。如图1.1所示，我们希望语言设计者不仅提供他们的语言规范，还提供关于各种服务所需的协议交互的信息。 从那里，我们可以得到"语言服务包"，其中是最小的独立语言服务相互交互。使用这些包，用户应该能够指定其IDE（或使用预定义的IDE）的配置和部署，以根据其工作环境和用例以他们需要的方式设置开发环境。开发人员需要对语言服务的最佳访问，而不管他们的工作场所和设备如何。随着COVID-19大流行，这一点变得更加明显9. cf. https://obeonetwork.github.io/GraphicalServerProtocol/第1章20图1.1
我的内容管理
展开
