Simplicitly: foundations and applications of implicit function types

Odersky, Martin; Blanvillain, Olivier; Liu, Fengyun; Biboudis, Aggelos; Miller, Heather; Stucki, Sandro

doi:10.1145/3158130

Cited by 30 publications

(35 citation statements)

References 26 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…The client/session tier-crossing primitives need to transmit values across the network. This requirement shows up in the API as type-classes encoded as Scala's implicit arguments [21,20]. All values that cross the network are required to be serializable, visible in our API as extra requirements on the type in form of: A: Encoder: Decoder.…”

Section: Crossing Client and Session Tiermentioning

confidence: 99%

Gavial: Programming the web with multi-tier FRP

2020

View full text Add to dashboard Cite

Web applications are inherently distributed, and not just because their client and server counterparts run on networked systems. Web applications are written in multiple programming languages and as multiple programs: the server and client programs. In an effort to lower the complexity of the web, multi-tier programming was proposed. In multi-tier programming languages the language and its tooling give support to create web applications as a whole, one program is written in one language.Web applications are also inherently asynchronous. On the server, they constantly process several client requests and in the browser they constantly have to react to input, be it from the user or a server. A technique that can be applied to make such programs easier to understand is functional reactive programming. A functional programming model that models an interactive program as compositions between two primitives, behaviors and events.Developing web applications requires dealing with their distributed nature and the natural asynchronicity of user input and network communication. For facilitating this, different researchers have explored the combination of a multi-tier programming language and functional reactive programming. However, existing proposals take his approach only part of the way. Some parts of the application remain imperative, do not consider network traffic overhead of incremental data, compatibility with common APIs like XMLHttpRequest etc., or they do not consider glitches across network communication (or do but introduce locking or overhead)In this paper, we present Gavial: a design and practical implementation of multi-tier FRP that allows constructing a web application as a functionally reactive program. We propose a novel integration of existing techniques such as solutions to bootstrapping web applications, recursive behaviors for web interfaces, asynchronous FRP and incremental behaviors. As well as novel support for tiered glitch freedom, a compromise between performance and glitch-free evaluation of the distributed FRP program, and a three-tiered system suitable for request-response-style applications as well as user-to-user applications. Gavial automatically runs in request-response (XMLHttpRequest) mode or in websocket mode.After applying a number of old and new ideas to create a practical multi-tier FRP implementation in Gavial, we demonstrate it by building an example and show that it can in fact deal realistically with important practical aspects of building web applications. At the same time, we retain the declarative nature of FRP, where behaviors and events have an intuitive, compositional semantics and a clear dependency structure. ACM CCS 2012Listing 2 Delayed DBehavior object DBehavior { def delayed[A](db: ⇒ DBehavior[A]): Behavior[A] }Returning to CircleRoyale, a type Player represents a player's position, and whether he is alive, attacking or dead. The svg method produces the player's circle and optionally the attacking circle as SVG elements. case class Player(position: Vec2D, attacking: ...

show abstract

Section: Crossing Client and Session Tiermentioning

confidence: 99%

Gavial: Programming the web with multi-tier FRP

2020

View full text Add to dashboard Cite

show abstract

“…Stainless relies on Scala compiler front ends to obtain a symbol-resolved syntax tree. For example, implicit parameters in Scala [Odersky et al 2018] become ordinary explicit parameters by the time Stainless processes them. Conversely, many of the types we define in System FR do not have their counterparts in Scala.…”

Section: Related Workmentioning

confidence: 99%

System FR: formalized foundations for the stainless verifier

Hamza

Voirol

Kunčak

2019

Proc. ACM Program. Lang.

View full text Add to dashboard Cite

We present the design, implementation, and foundation of a verifier for higher-order functional programs with generics and recursive data types. Our system supports proving safety and termination using preconditions, postconditions and assertions. It supports writing proof hints using assertions and recursive calls. To formalize the soundness of the system we introduce System FR, a calculus supporting System F polymorphism, dependent refinement types, and recursive types (including recursion through contravariant positions of function types). Through the use of sized types, System FR supports reasoning about termination of lazy data structures such as streams. We formalize a reducibility argument using the Coq proof assistant and prove the soundness of a type-checker with respect to call-by-value semantics, ensuring type safety and normalization for typeable programs. Our program verifier is implemented as an alternative verification-condition generator for the Stainless tool, which relies on the Inox SMT-based solver backend for automation. We demonstrate the efficiency of our approach by verifying a collection of higher-order functional programs comprising around 14000 lines of polymorphic higher-order Scala code, including graph search algorithms, basic number theory, monad laws, functional data structures, and assignments from popular Functional Programming MOOCs.

show abstract

“…As the compiler synthesises the missing arguments at compile-time from type information, calculi for implicit arguments might be best understood not as programming languages, but as meta-programming systems that generate code in a base language L from input programs in L with implicits. Indeed, SI [7], an extension of System F, Scala's foundations for implicits, does not have a selfcontained operational semantics, and is instead compiled to System F. We use the same approach, and translate IM to LAST.…”

Section: The Language Immentioning

confidence: 99%

“…A key notion in session types is that of duality, originating in linear logic: processes P and Q can be callee, and cannot be context dependent. Implicit arguments, a strict generalisation of default parameters, were pioneered in Haskell [6], and popularised as well as refined in Scala [7]: they separate the callee's declaration that an argument can be elided, from the caller's choice of elided values, allowing the latter to be context dependent. In this example f 2 is rewritten as above, but f 5 becomes f 5 (>), i.e.…”

Section: Introductionmentioning

confidence: 99%

“…The implicit scope can be thought of as a store of variables that are designated as implicit -we make this notion more precise in Section IV. Following [7], we do not give names to implicit variables until after translation, but use (pronounced 'query') as a placeholder name for all implicit variables. The translation becomes: let p = let c = accept x in let n, c = receive c in c in p let q = let y = 10 in let d = request x in d send y d in q…”

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

Asynchronous sessions with implicit functions and messages

Jeffery

Berger

2019

Science of Computer Programming

View full text Add to dashboard Cite

Session types are a well-established approach to ensuring protocol conformance and the absence of communication errors such as deadlocks in message passing systems. Haskell introduced implicit parameters, Scala popularised this feature and recently gave implicit types first-class status, yielding an expressive tool for handling context dependencies in a type-safe yet terse way. We ask: can type-safe implicit functions be generalised from Scala's sequential setting to message passing computation? We answer this question in the affirmative by presenting the first concurrent functional language with implicit message passing. The key idea is to generalise the concept of an implicit function to an implicit message, its concurrent analogue. Our language extends Gay and Vasconcelos's calculus of linear types for asynchronous sessions (LAST) with implicit functions and messages. We prove the resulting system sound by translation into LAST. † Extended abstract. We thank S. Gay, A. Scalas and V. Vasconcelos for valuable feedback on the present work. composed in parallel only when throughout the course of the computation each output of P 's is matched by a suitable input of Q's, and vice versa. Session types allow only dual processes to interact. Hence typability guarantees the absence of communication errors such as mismatched communication and deadlocks. A process Q, dual to P above, would have the session type

show abstract

Simplicitly: foundations and applications of implicit function types

Cited by 30 publications

References 26 publications

Gavial: Programming the web with multi-tier FRP

Gavial: Programming the web with multi-tier FRP

System FR: formalized foundations for the stainless verifier

Asynchronous sessions with implicit functions and messages

Contact Info

Product

Resources

About