38 karma · joined January 20, 2014
Here is the official acm link to the paper: https://dl.acm.org/doi/10.1145/3371071
Typed Racket uses macro expansion to translate its typed surface language into a typed core language, and then type checks that core language.
This approach works well because the surface and core languages are similar, and thus the type checker need only handle a small number of core forms.
This approach is limited, however, to constructs that are translatable into the core typed language. For example, a few Racket `for/X` comprehension forms are not supported in Typed Racket because they are difficult to translate.
Our approach alternatively uses macro expansion to type check the surface language and translates it into an untyped core language. Thus it's less limited in the typed languages one may implement. The tradeoff is that the programmer must implement type rules for all forms in the surface language, rather than just the core language.
Our approach uses macro expansion to typecheck the surface language and translates it into an untyped core language.
The two approaches should be considered alternative tools in a programmer's toolbox.
Yes. For example, see https://github.com/wilbowma/cur
Here's a summary from a presentation at the CUFP workshop (likely a shorter version of the slides above):
Dan Liebgold from Naughty Dog Software in Santa Monica then came on stage with the
first gaming related talk at CUFP. They produce the popular Uncharted game series for the
Playstation, which is famous for its complex and interactive scripted scenes. Dan described
modern game development as a major production effort where, roughly, artists produce
data and programmers produce code.
Naughty Dog has a history of using various Lisp dialects to handle the code and data in
a unified way. But when making the jump from the Playstation 2 to the Playstation 3, they
decided that maintaining a custom Lisp-based game development system was too costly,
and instead dedicated their efforts to rebuilding the tools, engine, and game in C++ and
assembly language.
This decision left no scripting system for gameplay and, more importantly, no system
for creating DSLs and the extensive glue data that is typically required to develop a major
video game. There was no off-the-shelf scripting system that fit the stringent memory
requirements in a Playstation 3, and no language that would allow rapid DSL creation
that fit into the existing tool chain.
With a bit of naivety, a penchant for the Scheme language, and a passion for functional
programming techniques, the team dove in and put together a system to fill in the gaps!
They used mzScheme, which can compile to fast native code. Dan reported that the results
have been very good, but not without issues. In particular, garbage collector performance
sometime led to manual tuning being required, and build environment integration was
tricky. Syntax transformations and error reporting led to confusion with new programmers
too.
On the other hand, the functional nature of the system was a big win, as it allowed
them to flexibly distill game data down to just the right form to embed into the resource-
constrained run-time environment. The final result is a system where programmers, artists,
animators, and designers are productively programming directly in an S-expression Scheme-
like language. Dan closed his talk by wowing the audience with the trailer for the game,
which has now been released and is garnering extremely positive reviews.
anil.recoil.org/papers/2011-cufp-scribe-preprint.pdfWhy does it matter what people do for leisure?
Try to add a static type system to Racket or Clojure. Oh but you don't have the ability to change the runtime system. With macros you can do it. See Typed Racket[2] or Typed Clojure[3].
[1]: http://docs.racket-lang.org/ [2]: https://github.com/plt/racket/tree/master/pkgs/typed-racket-... [3]: https://github.com/clojure/core.typed
This is not correct. To understand why, please see Ryan Culpepper's answer to this SO question:
http://stackoverflow.com/questions/7046950/lazy-evaluation-v...