For those of you who were able to attend my TrumpScript presentation on Friday, thank you! As promised, here is a more detailed technical report on the language.

TrumpScript is a concurrently compiled, statically typed, and procedural programming language written in Swift and C++. Unlike single-pass languages, TrumpScript is designed for parallel compilation. Because of an extended development process, TrumpScript has several different versions. For the sake of this discussion, I will refer to these variants as Implementations A, B, and C. While these are not implementations in the typical sense of the word – there are significant differences between each – they do share similar concepts and some code. Implementation A is interpolated only; Implementation B is incomplete. Implementation C, which was presented on Friday, should be considered the canonical version of TrumpScript.

In Implementation A, function, symbol, type, and operator tables are generated concurrently, and code is executed sequentially. Implementation A supports limited interpreter action, including function calls. Implementation C, on the other hand, is compiled using an L.L.V.M. intermediate representation (I.R.).

Using TrumpScript

TrumpScript is extremely C-like in nature. The terminology of TrumpScript, however, reflects its status as a satirical language. To declare a new constant, use the following syntax:

fact foo = 12

Similarly, a variable can be declared as follows:

altfact bar = 12

Explicit type declarations are not needed in TrumpScript; types are implicitly identified. To create a disfunction, simply type:

disfunc some() -> Huge {

    indict 32

}

The language is relatively simple, but it is quickly developing as I continue to expand the standard library (std in TrumpScript parlance). Loading in a file from the std is relatively simple, as demonstrated here with the math module:

tariff math

TrumpScript is capable of performing basic operations. In Implementations A and B, the programmer is able to define custom operators. This is a long-term goal for the current implementation, but is not yet complete. Similarly, although functions can be called in implementations A and B, function calling is not currently supported in implementation C. Steps have been made to rectify this situation, but I am not there quite yet.

TrumpScript operators are quite adept, and are able to differentiate between different input and output types, acknowledge precedence, and more. Thus the function

@main disfunc main() -> Huge {

    indict 1 + 3 * 12 + 6

}

would indict a value of 43 when called. Supported types currently include Huge (a 64-bit integer value), Claim (a boolean value, which may be set either to wrong or right), and Covfefe (a double-precision floating-point value). Custom type support is a possible future direction for Implementation C, and one supported to some extent by Implementation A.

Concurrent Compilation Background

For Implementation A’s concurrent interpretation of TrumpScript, I made use of concurrency features in the Swift programming language. These features were introduced to Swift relatively recently, but enable safe and modern concurrent approaches.

Implementations A and C both make use of async/await. Async/await is a model for achieving task-based concurrency. In an asynchronous await model, programmers identify points where it is safe to suspend execution on one function and resume or start execution on another.

The async/await paradigm does not inherently make code multithreaded. The purpose of the async/await model instead ensures that multithreaded coding is thread-safe. By defining arbitrary points where execution can be suspended, async/await ensures that the programmer does not need to worry about execution being suspended at other points. Yet although the paradigm is mostly effective, it does not guarantee thread safety: even when using async/await, race conditions remain possible.

Async/await is a relatively new approach to concurrency, developed during the aughts. The paradigm’s greatest benefit is that it can be added to code relatively easily, with minimal boilerplate code. Nevertheless, the async/await model continues to be improved. Haller et al. 2019 identified future improvements which could be made to the model, specifically by integrating async/await with observable objects, in order to enable asynchronous streams of programming.

In Swift, the async/await model allows for another key programming paradigm to be introduced: the actor. As explained by De Koster et al. 2016, actors rely on a principle of isolation. Actors help prevent race conditions by preventing their internal state from being written to by anything other than their own functions. Moreover, actors may only execute a single function at a time; any function called on an actor is added to a sequentially executed queue. This means that although actors are thread-safe, they can be performance bottlenecks for multithreaded code.

Swift’s implementation of actors is relatively intuitive. Unfortunately, however, the constraints inherent to using actors make converting an existing type into an actor a disfavorable proposition. Nevertheless, actors are found in all implementations of TrumpScript, and are key to enabling multithreaded interpretation and compilation.

Although actors and async/await options are useful for ensuring thread safety, they do not enable concurrency by themselves. Swift allows programmers the options of directly creating threads, as well as a task model.

Swift’s task model provides a useful abstraction for threads; it can make use of so-called ”virtual threads” and manages the actual number of threads used based on available system resources. Tasks can be created within the context of any function, but for optimal performance, it is best to create them within a TaskGroup, which can be instructed to execute its tasks in a number of different ways.

In Implementation A, for example, a TaskGroup is used to effectively construct an implicit barrier guaranteeing specific state promises before executing it constructs the symbol table. A similar approach is intended for use with Implementation C, which already has actors and async/await compliant functions ready for use.

Language Development

All TrumpScript implementations build lookup tables early in the compilation or interpretation process. These lookup tables use a combination of sets and dictionaries, both of which have O(1) performance time in Swift when used to look up values.

Unfortunately, however, Swift’s sets and dictionaries are not thread-safe. In order to use them safely, I include them either as properties in actors, or, as in one case in Implementation C, on a class restricted to use on a single thread. This approach allows me to safely use these high performance structures despite their lack of multithreaded safety guarantees.

As previously discussed, there is significant overlap between different implementations of TrumpScript. This overlap is particularly noteworthy in the first part of compilation: the lexer.

Tokenizing and delineating code is the first step in all three implementations of TrumpScript. The design of tokens has evolved significantly, however; whereas Implementations A and B used custom token enumerations, Implementation C uses a simple structure wrapper around a text value associated with dozens of computed boolean properties. This approach allows me to easily and elegantly adjust my regex matching without needing to worry about multiple occurrences of the same check throughout my codebase.

All variants of TrumpScript are careful to record user-observed line numbers. This is used to ensure high-quality error checks, particularly in Implementations A and B. (Implementation C currently relies on a whole lot of fatalError(:_) calls, but this is expected to change in the near future.)

Parallel compilation is not yet fully functional for implementation C, but it is almost ready, and will follow the design used in Implementation A, which builds tables in several groups: in each group, tables are generated independently; each group has dependencies on tables introduced in earlier groups. Implementation A uses a generate() function to prepare for interpretation; Implementation C uses a similar compile(:_) function to pipeline the TrumpScript code to machine code.

Although traditional strong/weak scalability testing is not appropriate for task-based concurrency, the parallel version of the generate() method in Implementation A is noticeably faster than the linear version, despite the fact that they ultimately perform the exact same tasks. Performance improvements can be measured by analyzing the time taken to complete all code in the generate method. Over multiple tests, performance improvements in the parallel version averaged 23 percent faster than the linear equivalent.

To enable compilation in Implementation C, I made use of the L.L.V.M. abstract assembly language. L.L.V.M. is an efficient approach to compilation because of its broad usage, robust support, and plentiful compiler targets. Rather than using L.L.V.M. code generation options, I opted to generate I.R. through my own files and pass my IR directly to the L.L.V.M. code, which I called from my C++ file. In turn, Swift was able to call my C++ function thanks to a bridging header.

In order to maximize the efficiency of my compiled code, I have the L.L.V.M. A.P.I. perform multiple optimization passes to fold constants, to remove unnecessary stack allocations, and to maximize computational speed and efficiency. All told, the resulting assembly code is remarkably efficient.

Acknowledgements

The satire and technical complexity of TrumpScript have made it an exciting project. I imagine I will continue working on it in the future. But even at its current state, quite a few people deserve thanks for their part in bringing it to life.

My thanks to the advice and support of Professors Paul Cantrell, Libby Shoop, Jed Carlson, and Lauren Milne, all of Macalester College. Thank you to the many people who suggested hilarious terminology and laughed alongside me as I worked on the language and my presentation. Building such a complex system is no simple feat, and I couldn’t have it without so many wonderful people working alongside me.

Finally, thank you to my brother, Milo, who flew halfway across the United States to see me present TrumpScript. It’s been great hanging out with you, and thank you for putting up with me.