{'fraction_non_alphanumeric': 0.01775625504439064, 'fraction_numerical': 0.003228410008071025, 'mean_word_length': 5.358974358974359, '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}}
Parallel Functional Languages Should be Strict

We argue here that the lazy evaluation strategy of pure functional languages is not suited to the needs of the massively parallel programmer. Lazy evaluation has the unwanted property of hiding complexity from the programmer, thus preventing a precise control of hardware resources. On the other hand, imperative languages are transparent in the sense of making complexity explicit in the syntax. This makes the latter far better tools for high performance applications because they allow the programmer to guess what effect syntactic changes will have on efficiency. Nevertheless, the clarity and abstraction of functional languages make them desirable vehicles for complex parallel software and there is much ongoing research aiming to resolve this dilemma. To minimise the above-mentioned disadvantage, we propose the strict evaluation strategy as a compromise between lazy functional programming and imperative programming. To make the argument precise we use a simple hypergraph model of execution, thus presenting evaluation strategies as computational problems whose input is the program’s syntax. The notion of P-completeness is related to those problems. Keyword Codes: C.1.2; D.1.1