Integrating typed and untyped code in a scripting language

Wrigstad, Tobias; Nardelli, Francesco Zappa; Lebresne, Sylvain; Östlund, Johan; Vítek, Jan

doi:10.1145/1707801.1706343

Cited by 27 publications

(17 citation statements)

References 24 publications

(18 reference statements)

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Operations applied to JavaScript types are always checked at run-time (by the JavaScript VM). This property makes JavaScript types behave similarly to the like types proposed by Wrigstad et al [23], with the exception that casts from non-conforming types must be explicit. Table 2 recaps all the interoperability semantics of expressions manipulating values of JavaScript types.…”

Section: Methods Callsmentioning

confidence: 77%

Semantics-driven interoperability between Scala.js and JavaScript

Doeraene

Schlatter

Stucki

2016

Proceedings of the 2016 7th ACM SIGPLAN Symposium on Scala

View full text Add to dashboard Cite

Hundreds of programming languages compile to JavaScript. Yet, most of them fail, at one level or another, to provide satisfactory interoperability with JavaScript APIs. This is limiting, as interoperability is at least required to manipulate web pages through the DOM API, but also to use the ecosystem of existing JavaScript libraries. This paper presents the interoperability features of Scala.js, which solves the shortcomings of previous approaches. Scala.js offers a separate hierarchy of JavaScript types, whose operations have semantics borrowed from ECMAScript 2015. The interoperability features are complete with respect to ECMAScript 2015, save for two exceptions which are still being worked on. This allows Scala.js programs to perform any operation that an ECMAScript program could do, thereby guaranteeing that they can talk to any JavaScript library.

show abstract

Section: Methods Callsmentioning

confidence: 77%

Semantics-driven interoperability between Scala.js and JavaScript

Doeraene

Schlatter

Stucki

2016

Proceedings of the 2016 7th ACM SIGPLAN Symposium on Scala

View full text Add to dashboard Cite

show abstract

“…Like types [41] bring some of the flexibility of dynamic typing to statically typed languages. The goal of these systems is to allow mixing of typed and untyped code.…”

Section: Related Workmentioning

confidence: 99%

Just-in-time static type checking for dynamic languages

Ren

Foster

2016

SIGPLAN Not.

View full text Add to dashboard Cite

Dynamic languages such as Ruby, Python, and JavaScript have many compelling benefits, but the lack of static types means subtle errors can remain latent in code for a long time. While many researchers have developed various systems to bring some of the benefits of static types to dynamic languages, prior approaches have trouble dealing with metaprogramming, which generates code as the program executes. In this paper, we propose Hummingbird, a new system that uses a novel technique, just-in-time static type checking, to type check Ruby code even in the presence of metaprogramming. In Hummingbird, method type signatures are gathered dynamically at run-time, as those methods are created. When a method is called, Hummingbird statically type checks the method body against current type signatures. Thus, Hummingbird provides thorough static checks on a per-method basis, while also allowing arbitrarily complex metaprogramming. For performance, Hummingbird memoizes the static type checking pass, invalidating cached checks only if necessary. We formalize Hummingbird using a core, Ruby-like language and prove it sound. To evaluate Hummingbird, we applied it to six apps, including three that use Ruby on Rails, a powerful framework that relies heavily on metaprogramming. We found that all apps typecheck successfully using Hummingbird, and that Hummingbird's performance overhead is reasonable. We applied Hummingbird to earlier versions of one Rails app and found several type errors that had been introduced and then fixed. Lastly, we demonstrate using Hummingbird in Rails development mode to typecheck an app as live updates are applied to it.

show abstract

“…Gradualtalk is based on Siek and Taha's gradual typing approach. Some other popular partial typing techniques are soft typing [1], pluggable types [3], hybrid typing [4] and like types [38]. Soft typing is a static type system that does not reject potentially erroneous programs, but inserts casts to ensure safety.…”

Section: Related Workmentioning

confidence: 99%

Gradual typing for Smalltalk

Allende

Callaú

Fabry

et al. 2014

Science of Computer Programming

View full text Add to dashboard Cite

Being able to combine static and dynamic typing within the same language has clear benefits in order to support the evolution of prototypes or scripts into mature robust programs. While being an emblematic dynamic object-oriented language, Smalltalk is lagging behind in this regard. We report on the design, implementation and application of Gradualtalk, a gradually-typed Smalltalk meant to enable incremental typing of existing programs. The main design goal of the type system is to support the features of the Smalltalk language, like metaclasses and blocks, live programming, and to accomodate the programming idioms used in practice. We studied a number of existing projects in order to determine the features to include in the type system. As a result, Gradualtalk is a practical approach to gradual types in Smalltalk, with a novel blend of type system features that accomodate most programming idioms.

show abstract

Integrating typed and untyped code in a scripting language

Cited by 27 publications

References 24 publications

Semantics-driven interoperability between Scala.js and JavaScript

Semantics-driven interoperability between Scala.js and JavaScript

Just-in-time static type checking for dynamic languages

Gradual typing for Smalltalk

Contact Info

Product

Resources

About