Sustainable Data Centers

. In software programming, this is done by means of a piece of code, and/or by various types of inputs. In this process, it is crucial for us to track the impact of those codes and inputs, otherwise known as “effect checking.”

Effect Checking

Tracking the impact of codes and inputs in software programming.

Why do we use computers? The obvious answer is that we seek some result, or effect, in the real world. In software programming, this is done by means of a piece of code, and/or by various types of inputs. In this process, it is crucial for us to track the impact of those codes and inputs, otherwise known as “effect checking.” Over the last three decades, numerous researches have focused on the subject of effect checking, which has resulted in a strong repository of effect systems designed for several effect domains such as I/O, exceptions, locking, atomicity, confinement, and purity. However, most of the researches have been unable to adopt the effect systems in practice.

In this backdrop, a new approach toward effect testing is being presented by an ongoing research at EPFL’s Programming Methods Laboratory. Rather than focus on “effects,” this new approach centres on “capabilities.” The research, which has already received funding from the Swiss National Science Foundation, is headed by Martin Odersky, professor of programming methods at EPFL and the creator of the Scala programming language.

In his research papers, Professor Odersky has highlighted the reasons for effect systems not coming into the mainstream as much as type systems. Even where the static effect discipline has been used successfully, like Java’s system of checked exceptions, doubts are beginning to surface, mainly because of the lack of polymorphism and the transfer of the burden of tracking effects to the programmer. To avoid such pitfalls, the ongoing research switches the argument around by treating effects as capabilities. This presents a straightforward method to express “effect polymorphism,” i.e., the ability to write a function once and let it interact with arguments that can lead to random effects.

To render capabilities more robust and useful, the research uses the concept of “implicit parameters,” and then abstracts these parameters into implicit function types. It has also devised a “pure function” type to deal with the basic difference between capabilities and effects, viz., capabilities can be captured in closures, while effects are temporal.

The research is still very much a work in progress. By delving into the concept of effects as capabilities, it aims to examine encodings of higher-level language constructs, build a theoretical model, and develop specifications to implement effects in Scala.

Suggested readings:

http://ecocloud.ch/2017/02/06/effects-as-implicit-capabilities-project-receives-funding/
http://p3.snf.ch/Project-166154#
http://program-transformation.org/WGLD/Meeting2016
http://materials.dagstuhl.de/files/17/17051/17051.NadaAmin.ExtendedAbstract.pdf
https://jaxenter.com/current-state-scala-odersky-interview-129495.html