跨平台语言设计：兼顾移植性和互操作性

需积分: 3 11 浏览量更新于2024-07-18 收藏 1.49MB PDF 举报

"Sebastien Doeraene的博士论文《跨平台语言设计》探讨了在多运行时环境下设计编程语言的挑战与策略，强调了语言的可移植性和互操作性。该论文指出，针对单一运行时设计的语言可以更好地适应其语义，但针对多个具有不同语义的运行时的语言设计则需要平衡各种需求。跨平台语言旨在实现跨平台编译并保持一致的行为，同时能够与同一平台上的其他语言有效地交互。" 在这篇博士论文中，Sebastien Doeraene深入研究了如何创建一个既能适应多种运行环境又能够与这些环境中其他语言无缝协作的语言。他指出，虽然许多跨编译语言侧重于其中一个特性（可移植性或互操作性），但一开始就兼顾两者的设计并不多见。论文可能涵盖了以下几个关键知识点： 1. **跨平台语言的概念**：跨平台语言是指设计用于在多个不同的硬件或软件平台上运行，并且能够在这些平台上保持一致行为和与其他语言交互的语言。 2. **可移植性**：这是指程序或库能够在多个平台上编译，并在所有平台上表现出相同的行为。实现可移植性通常涉及抽象化底层平台细节，使代码独立于特定平台。 3. **互操作性**：互操作性是指语言在同一个平台上能够与其他语言进行通信的能力，这通常涉及到接口设计、数据类型转换和调用约定等。 4. **多运行时环境**：随着编程语言编译到多种运行时，如JVM、JavaScript的V8引擎或.NET框架，每个运行时都有其特定的对象模型和其他结构。这为语言设计带来了挑战，因为需要适应不同的语义和特性。 5. **设计策略**：论文可能探讨了如何在设计语言时平衡不同运行时的需求，以确保跨平台的兼容性和与其他语言的互操作性，可能包括元编程、类型系统的设计以及编译器优化等方面的策略。 6. **案例分析**：可能通过分析现有的跨平台语言（如C++、Java或Rust）来展示它们是如何处理可移植性和互操作性的，并从中提取经验教训。 7. **评估与测试**：论文可能会介绍如何评估一个跨平台语言在不同环境下的表现，以及如何确保其在所有目标平台上的行为一致性。 8. **未来研究方向**：Sebastien Doeraene可能提出了对跨平台语言设计的未来研究方向，包括可能的技术改进、新的设计模式或者标准化的建议。这篇论文对于理解跨平台编程语言的设计原则和挑战，以及如何构建更强大的多语言生态系统具有重要的理论和实践价值。通过深入阅读，开发者和研究人员可以获取有关如何设计高效、灵活且兼容性强的跨平台语言的宝贵见解。

Chapter 1. Introduction

of the language that can be compiled to multiple runtimes, with more or less equivalent

semantics. Here also, the extent of this subset varies across languages, ranging from virtually

nonexistent (usually by design, as in PureScript if we compare it to its big brother Haskell,

in this case due to the strict versus lazy evaluation semantics) to mostly equivalent with

exceptions (for example, numbers in ClojureScript versus Clojure) to near-perfect emulation

(typically found in embedded VMs such as Doppio [66]).

The quality of a language’s portability has a direct consequence on its ecosystem of libraries.

Speciﬁcally, how many libraries can be reused across runtimes, and how easily. In practice,

even if the language itself is portable, unless the ecosystem follows suit and publishes portable

libraries, it remains difﬁcult to do any meaningful job spanning several runtimes. An example

of this phenomenon, as of 2018, is Kotlin [

], which is itself relatively portable, but whose

ecosystem, for the most part, sticks to the JVM target. A plausible cause is that until recently

(November 2017), Kotlin did not provide a good practical story for a library to target multiple

platforms. At the other end of the spectrum, Haxe [

], whose top-level documentation pages

include a showcase of cross-platform libraries, is probably the language most known for

having a multi-runtime ecosystem.

These two properties, interoperability and portability, are at the heart of what we call a cross-

platform language. Libraries and applications can cross-compile for multiple targets and

behave the same way everywhere, and they can interoperate with their respective platforms.

Surprisingly, few languages are really designed from the get-go to extensively feature both

properties at once, focusing instead on one of them and patching some support for the other

as an afterthought. This thesis aims at tackling this dual goal in a principled way, essentially

doing cross-platform language design.

Although the “philosophy” described in this thesis should transfer to any cross-platform

language, we will focus our technical discussion on the challenges and decisions arising from

combining JavaScript and the JVM as two target platforms. More speciﬁcally, we study the

design of Scala.js [

], the dialect of Scala targeting the JavaScript platform. This dialect was

designed and implemented from the very early stages (literally the ﬁrst few weeks) with the

goal of interoperability in mind. Very quickly, we realized that the dialect could not take off

without strong portability as well, due to the existing ecosystem of libraries targeting the JVM

and relying on more JVM-speciﬁc behaviors than one would like. This pair of goals turned

out to be somewhat conﬂicting, as we will see in Chapter 2, forcing the design to include

some trade-offs on one side or the other. On top of that, since Scala.js was meant to be a

practical tool for production use, performance of the compiler and the generated code was an

important concern, and that, too, forced some trade-offs with interoperability and portability.

This dissertation articulates those three goals throughout.

1.1. Software

1.1 Software

Although this dissertation does not directly depend on it, we cannot ignore the actual im-

plementation of Scala.js. Its main website is https://www.scala-js.org/, and its source code,

at the time of writing, is available on GitHub at https://github.com/scala-js/scala-js.

speciﬁcally, this thesis refers to Scala.js 1.0.0-M5. The ﬁle

DEVELOPING.md

gives information

about the structure of the project, and how to build and test it. Besides the author, the main

contributors to this project, and more importantly the ideas and designs behind it, are Tobias

Schlatter and Nicolas Stucki.

1.2 Overview

This dissertation comprises 3 chapters, going from the designs at the Scala.js source code level,

down to the implementation.

Chapter 2 gives further motivation for portability and interoperability, and makes those

notions more precise. We describe the main portability challenges of Scala.js and how they are

overcome. We brieﬂy evaluate portability in terms of how much of the Scala/JVM test suites

pass on Scala.js. Afterward, we dive deeper into the design of interoperability between Scala.js

and JavaScript. We give an objective measure of interoperability, which is completeness with

respect to the semantics of the host language, and show that Scala.js satisﬁes this measure—

with the exception of one particular JavaScript feature, namely new.target.

Because Scala as a source language is a complex beast, reasoning well enough about it to

optimize it is virtually impossible. Chapter 3 gives a speciﬁcation of the Intermediate Rep-

resentation (IR) used by Scala.js, which tightly integrates portability and interoperability

features. We also present some fundamental properties of the IR that are necessary to build

optimizations on top of it.

Finally, Chapter 4 discusses how the IR is optimized and eventually compiled down to

JavaScript. In particular, we elaborate on the incremental parallel nature of the whole-program

optimizer and on speciﬁc optimizations that we apply to 64-bit integers. We conclude with a

performance evaluation of programs emitted by the Scala.js compiler toolchain.

Should this link be invalidated in the future, it should always be possible to ﬁnd the source code through the

main website.

Chapter 1. Introduction

1.3 Contributions

The main contributions of this thesis are the following:

•

We give an objective measure for the quality of interoperability in a cross-platform

language, as completeness with respect to the semantics of the host language. The

criterium is given in Section 2.2.6, and drives the design of all the interoperability

features of Scala.js in Section 2.2. It can be used in the design of other cross-platform

languages, irrespective of their target platform. Completeness gives the guarantee

that programs written in the cross-platform language can use any library of the host

language.

•

We give the deﬁnition of an intermediate representation, the Scala.js IR, with precise

syntax, type system and run-time semantics, in Chapter 3. This IR is used as a contract

between the compiler front-ends (for various versions of Scala.js, or even other lan-

guages) and the optimizer and emitter to JavaScript. It features both statically typed

JVM-like operations and dynamically typed JavaScript operations in a uniﬁed type sys-

tem. The type system is expected to be sound, and IR programs live in a closed world,

which provides the foundations for whole-program optimizations to be applied.

•

We show a novel approach to designing parallel and incremental whole-program opti-

mizers, in Section 4.2. The approach is based on so-called knowledge queries, which

create a modular interface between incremental changes in a program and the opti-

mizations they invalidate. We used this approach to build the whole-program optimizer

of Scala.js, whose incremental runs exhibit 10 to 100 running time improvements over

batch runs.

•

We present a fast implementation of 64-bit integers for the JavaScript platform, in

Section 4.4. It is 3.6x to 60x faster than existing approaches, and only about 3–5x slower

than the native implementation of 32-bit integers. This implementation could transfer

to any statically typed language compiling to JavaScript, solving the tension found in

previous compilers to JavaScript between fast-but-incorrect and correct-but-slow 64-bit

integers.

Chapter 2

Cross-Platform Language Semantics

At the heart of every programming language stands its semantics. In the context of a cross-

platform language, the semantics needs to address both portability and interoperability. As

we introduced in the previous chapter, portability is the property that a program can compile

and have the same behavior across platforms, i.e., its semantics is portable across platforms.

Interoperability is the ability to communicate with other languages on each target platform,

i.e., the semantics needs to be shared with other languages on the same platform. Obviously,

not all of a language’s semantics can be portable and interoperable at the same time. If that

were true, the various platforms would have equivalent semantics, and we would therefore not

consider them as separate platforms to begin with. Nevertheless, featuring both portability

and interoperability is not a lost cause. Rather, some aspects of the language semantics should

target portability, and some others should target interoperability.

In the context of Scala.js, portability is measured with respect to Scala/JVM, while interoper-

ability is measured with respect to JavaScript. In this chapter, we explore the most relevant

semantics of Scala.js as seen from those two angles. We ﬁrst build the foundations through

portability, then expand the reach of Scala.js through interoperability. This makes sense be-

cause of the prior existence of Scala/JVM, which constrains the design. When designing a

fresh language, those two processes are much more interleaved, and woven together. Despite

the constraints imposed by Scala/JVM, some portability was sacriﬁced after the fact in Scala.js

to improve interoperability and performance, and will be described in the respective sections.

2.1 Building the Foundations: Portability

Since the JVM has long been the only platform supported by Scala,

there are two different

ways one can think about the semantics of Scala. On the one hand, we can follow the Scala

An effort to port Scala to .NET was attempted but later abandoned.

Chapter 2. Cross-Platform Language Semantics

Language Speciﬁcation [

] to the letter. On the other hand, we can observe how Scala/JVM

behaves and deﬁne the semantics of Scala as the observed behavior. In theory, the former is

the obvious good choice, because it is a principled approach, and because the speciﬁcation

leaves the semantics of some constructs as implementation-deﬁned, potentially increasing

our freedom as the designer of a dialect for another platform. Unfortunately, in practice

we must account for an external agent: the ecosystem of existing libraries. As we saw in

the previous chapter, when designing a cross-platform language, it is not sufﬁcient for the

language itself to be portable; so must the libraries. The trouble is that, being exposed only

to Scala/JVM, library developers have (perhaps unknowingly) relied on some behavior of

Scala/JVM that is technically implementation-deﬁned according to the speciﬁcation. These

behaviors are de facto semantics, and must be taken into account when considering portability

of the language. As our implementation of Scala.js reached more libraries, we progressively

realized that virtually every corner of the speciﬁcation that was left to the implementation

had been turned into de facto semantics in more or less critical ways. Therefore, we had no

choice but to consider de facto semantics as an integral part of the Scala speciﬁcation, and we

sometimes call the combination of both as the Scala/JVM speciﬁcation.

In this section, we discuss some parts of the Scala/JVM speciﬁcation, including de facto

semantics, that have a non-trivial impact on Scala.js, notably on interoperability. Beyond

the case of Scala.js, illustrating these aspects can also serve as a check-list of things to look

out for when designing a cross-platform language from scratch. Throughout this section,

we justify decisions based on arguments such as “the ecosystem did/did not rely on some

speciﬁc behavior”. Those observations came from experience, trying to implement alternative

behaviors and watching the ecosystem survive them, or breaking down. We did not actually

record empirical data as we progressed, therefore those arguments unfortunately remain

anectodal.

The “ecosystem” itself is difﬁcult to deﬁne. For Scala.js, it even progressed over time, as the

development of the language matured. At ﬁrst, approximately until Scala.js 0.4.x, i.e., one year

of development, it only consisted of early adopters: users who were willing to play with an

immature technology and report immediate limitations. The feedback from early users was

crucial to make the language usable at all. Once Scala.js addressed immediate needs, the pool

of early adopters grew into a small community of enthusiasts. That community developed

initial libraries, or tried to port existing libraries, exhibiting new requirements. So far, only

users speciﬁcally interested in the JavaScript platform tried to use Scala.js. The last critical

step was to make the language portable enough for large existing libraries to cross-compile

as-is, and to provide the necessary tooling to make it as easy as possible to do so, which

was the main focus of the transition from 0.5.x to 0.6.x, approximately two years into the

development. At that point, the ecosystem suddenly exploded, as more and more established

libraries from the Scala/JVM ecosystem started cross-compiling for Scala.js. In the process,

the test suites of these libraries started exercising all the possible obscure de facto semantics

of Scala/JVM. Unlike the two ﬁrst phases of the development, where requirements and bugs

were only elicited by isolated experiments done by users, this third phase creates many more

剩余183页未读，继续阅读

wj16account

粉丝: 3
资源: 5

跨平台语言设计：兼顾移植性和互操作性

Java-curriculum-design-thesis.rar_java课程设计_计算器

whu-thesis-master.zip

Write a 5,000-word thesis on "Application of Sandbox Technology in Cybersecurity Engineering."

我想要CCT的latex的模板

Graduate thesis in financial management

训练过程中 WARNING: D:\Speace\thesis\yolov5-master\datasets\diedao\images\train\IMG_20240104_141435.jpg: corrupt JPEG restored and saved

write a thesis about scientific activity survey in middle school

C PLUS PLUS

spea python代码实现完整代码

从字符串E:/05Thesis_Code/07Thesis_Code_All/CamVid_main/camvid/images/0001TP_009210.png中获取0001TP_009210，给出代码

最新资源