{'fraction_non_alphanumeric': 0.023413897280966767, 'fraction_numerical': 0.0, 'mean_word_length': 4.968468468468468, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Principal Typings for All Normalizable Terms in the System of Intersection Types With Expansion Variables

The history of software engineering is littered with examples of programming errors. Despite years of expensive research into the failures of software systems, today’s software is notorious for being buggy, unreliable, and incapable of exploiting the full power of our hardware. It has been demonstrated that type systems can reduce at compile time (i.e., statically) the frequency and severity of many programming errors. The purpose of program analysis is to ensure that a software system behaves correctly with respect to some specification. Many type-based program analyses have worked best as a form of whole-program analysis. This means that a change to one part of the software system requires reanalyzing all parts. Today’s software systems are huge and necessarily modular (i.e., they are built up from smaller components). Source code is split into different modules and saved to many files that are updated at different times. Since most of the common program analysis techniques are not linear in complexity, requiring the reanalysis of a large program due to a single line change is extremely costly. In such an environment, whole-program analysis is simply unmanageable. A modular approach is necessary.