Capabilities: Effects for Free

Craig, Aaron C.; Potanin, Alex; Groves, Lindsay; Aldrich, Jonathan

doi:10.1007/978-3-030-02450-5_14

Cited by 7 publications

(4 citation statements)

References 14 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…The rules for contraauth thus mirror those for auth with the exception that contra-auth does not capture the effect of the method itself because that method is from the original caller, not the callee-the callee may not even invoke it! This form of analysis follows the general rule of contravariant function types, but it also more specifically echos the capability-based, effect-bounding analysis of Craig et al [2018].…”

Section: Authority Provided By An Object a Basic Notion In The Author...mentioning

confidence: 97%

Bounded Abstract Effects

Melicher

Zhao

et al. 2022

ACM Trans. Program. Lang. Syst.

Self Cite

View full text Add to dashboard Cite

Effect systems have been a subject of active research for nearly four decades, with the most notable practical example being checked exceptions in programming languages such as Java. While many exception systems support abstraction, aggregation, and hierarchy (e.g., via class declaration and subclassing mechanisms), it is rare to see such expressive power in more generic effect systems. We designed an effect system around the idea of protecting system resources and incorporated our effect system into the Wyvern programming language. Similar to type members, a Wyvern object can have effect members that can abstract lower-level effects, allow for aggregation, and have both lower and upper bounds, providing for a granular effect hierarchy. We argue that Wyvern’s effects capture the right balance of expressiveness and power from the programming language design perspective. We present a full formalization of our effect-system design, showing that it allows reasoning about authority and attenuation. Our approach is evaluated through a security-related case study.

show abstract

Section: Authority Provided By An Object a Basic Notion In The Author...mentioning

confidence: 97%

Bounded Abstract Effects

Melicher

Zhao

et al. 2022

ACM Trans. Program. Lang. Syst.

Self Cite

View full text Add to dashboard Cite

show abstract

“…One of the original goals for capability-based design is to reason about the effect of some code by reasoning about the capabilities it is provided [45,Ch. 8] -a long-standing practice based on the notion that capabilities essentially grant permission to cause effects, though until relatively recently [13,38,39] the exact relationship between static capabilities and static effects was left implicit. 5 However, the pure form of this approach -that the set of capabilities provided is used to give an upper bound on an expression's effect -has limitations we have not seen crisply articulated in a general way before.…”

Section: Capabilities Use and Mentionmentioning

confidence: 99%

“…But what does that gain us? As is known [42,13], an explicit effect system requires a system that cares about the details of the code being analyzed, which can require complex types and effects [1] (we see examples in Section 3). So concretely, what can effect systems offer that capability-based reasoning struggles with?…”

Section: The Gap Between Capability Bounds and Effects: Use-mention D...mentioning

confidence: 99%

Designing with Static Capabilities and Effects: Use, Mention, and Invariants

Gordon

2020

Preprint

View full text Add to dashboard Cite

Capabilities (whether object or reference capabilities) are fundamentally tools to restrict effects. Thus static capabilities (object or reference) and effect systems take different technical machinery to the same core problem of statically restricting or reasoning about effects in programs. Any time two approaches can in principle address the same sets of problems, it becomes important to understand the trade-offs between the approaches, how these trade-offs might interact with the problem at hand.Experts who have worked in these areas tend to find the trade-offs somewhat obvious, having considered them in context before. However, this kind of design discussion is often written down only implicitly as comparison between two approaches for a specific program reasoning problem, rather than as a discussion of general trade-offs between general classes of techniques. As a result, it is not uncommon to set out to solve a problem with one technique, only to find the other better-suited.We discuss the trade-offs between static capabilities (specifically reference capabilities) and effect systems, articulating the challenges each approach tends to have in isolation, and how these are sometimes mitigated. We also put our discussion in context, by appealing to examples of how these trade-offs were considered in the course of developing prior systems in the area. Along the way, we highlight how seemingly-minor aspects of type systems -weakening/framing and the mere existence of type contexts -play a subtle role in the efficacy of these systems.

show abstract

“…In particular, to create restricted effects (such as a ConsolePrint object over a Console one), a wrapper object needs to be explicitly created, whereas Callℇ's type system does not require any such input from the programmer. However, such problems with object-capabilities can be alleviated by using implicit parameters and/or variables which are kept in scope for entire modules [17], this is a simpler alternative to effect systems [1], but is weaker and less flexible.…”

Section: Object-capabilitiesmentioning

confidence: 99%

CallƐ: an effect system for method calls

Gariano

Noble

Servetto

2019

Proceedings of the 2019 ACM SIGPLAN International Symposium on New Ideas, New Paradigms, and Reflections on Programming and Sof

View full text Add to dashboard Cite

Effect systems are used to statically reason about the effects an expression may have when evaluated. In the literature, such effects include various behaviours as diverse as memory accesses and exception throwing. Here we present Callℇ, an object-oriented language that takes a flexible approach where effects are just method calls: this works well because ordinary methods often model things like I/O operations, access to global state, or primitive language operations such as thread creation. Callℇ supports both flexible and finegrained control over such behaviour, in a way designed to minimise the complexity of annotations.Callℇ's effect system can be used to prevent OO code from performing privileged operations, such as querying a database, modifying GUI widgets, exiting the program, or performing network communication. It can also be used to ensure determinism, by preventing methods from (indirectly) calling non-deterministic primitives like random number generation or file reading.

show abstract

Capabilities: Effects for Free

Cited by 7 publications

References 14 publications

Bounded Abstract Effects

Bounded Abstract Effects

Designing with Static Capabilities and Effects: Use, Mention, and Invariants

CallƐ: an effect system for method calls

Contact Info

Product

Resources

About