Denotational semantics of a para-functional programming language

Parallel functional languages often use meta-linguistic annotations to provide control over parallel evaluation. In this paper we explore a flexible mechanism to control when an expression is evaluated: first-class monadic schedules. We discuss the advantages of using such first-class values over traditional annotation-based systems. In particular, it is often desirable to make decisions about the operational behavior of parallel programs depending on the dynamic state of the system. For example, we may want to measure the system load before deciding to evaluate expressions in parallel. For this purpose, we show how monads can be used to access dynamic system parameters in a referentially transparent manner (up to termination).As a mechanism to reason about schedules, we present a set of algebraic properties that any implementation of schedules must satisfy. We also describe an implementation that translates schedules into a dialect of Scheme extended with futures. We prove that this implementation satisfies the given set of algebraic properties, and give performance results for a parallel solution to the n-body problem using the Barnes-Hut method.Although our ideas were developed specifically for nonstrict functional languages such as Haskell, we briefly discuss how they can be used with strict functional languages and imperative languages as well.

show abstract

“…Further, proving that such a property holds is much more cumbersome [Hudak 1986b] than that presented here.…”

Section: Getload : : Os Intmentioning

confidence: 95%

First-class monadic schedules

Mirani

Hudak

2004

ACM Trans. Program. Lang. Syst.

Self Cite

View full text Add to dashboard Cite

show abstract

“…In the field of engineering, the concept of para-functionality first appeared in the context of a methodology for programming multiprocessor computing systems (Hudak, 1986a). There, it augments functional programming models with features that allow programs to be mapped to specific multiprocessor topologies (Hudak, 1986b). It makes achieving the goals of a program possible in a holistic way and by providing additional capabilities (in the above case, for instance, complex message sending and synchronization among processors).…”

Section: Understanding and Implementation Issues Of Para-functions Of...mentioning

confidence: 99%

Designing next-generation cyber-physical systems: Why is it an issue?

Horváth

2023

JID

View full text Add to dashboard Cite

Cyber-physical systems (CPSs) are seen as one of the tangible results of the convergence of advanced information technology, nanotechnology, biotechnology, cognitive science, and social science in addition to conventional systems science, engineering, and technologies. Designing next-generation cyber-physical systems (NG-CPSs) is a challenging matter for abundant reasons. It is not possible to consider all reasons and to address their interplays simultaneously in one paper. Therefore, this position paper elaborates only on a selected number of topical issues and influential factors. The author claims that the shift of the paradigm of CPSs and the uncertainty related to the paradigmatic systems features of NG-CPSs are among the primary reasons. Since the future of CPSs will be influenced strongly by their intellectualization, adaptation/evolution, and automation, these aspects are also addressed. It is argued that interaction and cooperation with NG-CPSs should be seen from a multi-dimensional perspective and that socialization of NG-CPSs needs more attention in research. The need for aggregation, management, and exploitation of the growing amount of synthetic systems knowledge produced by smart CPSs is seen by the author as an important emerging concern.

show abstract

“…In earlier work on the formM semantics of para-functional programming languages we introduced a notion of execution trees to capture the evaluation history of a program [4]. However, execution trees, being trees, do not capture any notion of sharing, which is crucial to the semantics of, for example, lazy evaluation.…”

Section: W H Y P O M S E T S ?mentioning

confidence: 99%

“…This is necessary because we wish to provide an exact pomset interpretation, and thus we need to know the standard values of expressions in order to give proper meaating to, for example, conditionM expressions. 2Th]~ solution is similar to that used in various other semantics, including strictness analysis t9], execution-tree semantics [4], and sharing analysis [2]. B' simply wraps a "demand/return event pair" around an expression's pomset, which is in turn derived using B:…”

Section: ~T: E X P --* E N V --+ B E N V --* B E H ~: E X P --* E N Vmentioning

confidence: 99%

“…To capture this behavior it is obvious that the standard semantics must first be extended to include the meaning of the (dynamic) variable sell-this is very straightforward, and in fact is done in [4]. In addition, the pomset semantics must have some notion of processor names, and a mechanism to attach them to the pomsets representing expression evaluation.…”

Section: T H E O R T H O C U R R E N C E O F P R O C E S S a N D P R mentioning

confidence: 99%

See 1 more Smart Citation

Pomset interpretations of parallel functional programs

Hudak

Anderson

1987

Functional Programming Languages and Computer Architecture

Self Cite

View full text Add to dashboard Cite

A new framework is presented, based on the notion of a partially ordered multiset (or pomset), which is able to provide not only a precise operational semantics of parallel functional program evaluation, but also a handle through which to control such behavior. As an operational semantics, pomsets are able to distinguish between call-by-value, call-by-name, call-by-need, and call-by-speculation evaluation strategies (even though all but the first of these have the same standard semantics); and as a "handle" from which to control operational behavior, pomsets can express most of the behaviors achieved by previously proposed annotations that control not only evaluation order but also the spatial mapping of program to machine.

show abstract

Denotational semantics of a para-functional programming language

Cited by 7 publications

References 15 publications

First-class monadic schedules

First-class monadic schedules

Designing next-generation cyber-physical systems: Why is it an issue?

Pomset interpretations of parallel functional programs

Contact Info

Product

Resources

About