stchang

Correct. More specifically, type checking is performed as part of macro expansion, which happens at compile-time.

Thanks for the comment!

The submitted link might be an older preprint.

Here is the official acm link to the paper: https://dl.acm.org/doi/10.1145/3371071

Awesome! Would love to check it out once you have a prototype.

It could, though it's not clear whether it would be an improvement.

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.

Typed Racket uses macro expansion to translate its typed surface language into a typed core language, and then typechecks 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.

Can you do dependent types?

Yes. For example, see https://github.com/wilbowma/cur

Minor correction, Matthias created Racket.

It's a misunderstanding that has unfortunately caught on among many Haskell programmers. People who say "macros are only useful in strict languages" mistakenly think that macros can only be used to delay evaluation. Of course, there are many more uses of macros, as you point out. Macros can define new binding forms, e.g., in Racket, pattern matching is a library, while it in Haskell it must be part of the core language. Macros are also useful for abstracting over non-first-class language forms like top-level definitions, import/export statements, and even type definitions.

FWIW, the phase system that is the main topic of the article was created for Racket [1], though some Scheme macro systems have since adopted this Racket innovation.

[1] https://www.cs.utah.edu/plt/publications/macromod.pdf

Here's some more context info for the paper: http://2015.ecoop.org/event/research-track-towards-practical...

Yup! I meant that they switched from GOAL to Racket for the PS3.

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.

They switched to Racket when moving to the PS3. Here's a talk discussing the use of Racket in developing The Last of Us: https://www.youtube.com/watch?v=oSmqbnhHp1c

When moving to PS3, they used Racket instead.

https://www.youtube.com/watch?v=oSmqbnhHp1c

(presumably because you have lives)

Why does it matter what people do for leisure?

All of Racket's `#lang` family of languages are implemented with macros on top of core Racket. For example, Scribble, mentioned in another comment, is the documentation language used to author the article, and the Racket docs[1]). Or Slideshow, Racket's programmatic Powerpoint alternative.

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

Haskell, by its lazy evaluation, is basically a macro-only language

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...