How Does Static Typing Limit Macros?

Question

I was reading Paul Graham's "The Hundred-Year Language" article.

http://www.paulgraham.com/hundred.html

In there he makes a claim that static typing "preclude[s] true macros".

For example, types seem to be an inexhaustible source of research papers, despite the fact that static typing seems to preclude true macros-- without which, in my opinion, no language is worth using.

How is this true? Where are the papers? I tried searching on Google without success.

Beatnik

One piece of evidence in favor of Graham's assertion is that no one seems that interested in creating or using a statically-typed language that goes as far as Lisp does in the service of macros: more or less abandoning syntax to force everyone to think in terms of parse trees, which by the way can be represented as lists (the fundamental data structure of the language). There appear to be two defunct attempts to make it possible to write Haskell code in a Lisp-like format: Liskell and Lisk. – Dissipated

Answer 1

Static typing doesn't preclude macros. For example, the static-typed Boo language has macros. So does Nemerle.

However, it depends on what Graham means by "true" macros. Maybe Boo and Nemerle macros are "false" by his standards.

Operation

Answer 2

It isn't really true that static typing precludes macros, but it generally does mean that the macro system needs to be more complicated than the unhygienic text-substitution macros familiar to many. I'm not exactly sure what Graham is trying to get at here, or what he means by "true" macros.

See this paper for one take on hygienic macros in a statically typed context.

(Incidentally, I also don't agree that no language is worth using if it doesn't have macros. I think that first-class functions coupled with some of the more sophisticated modern type systems can elegantly solve most of the problems at which macros have traditionally been aimed.)

Olympia

link is dead. got the name of the paper? – Tartaric

Answer 3

"static typing seems to preclude true macros" How is this true?

Without a definition of "true macros" it is a meaningless claim but OCaml had both static typing and (AST-rewriting) macros before Paul Graham wrote that. He could easily have discovered that for himself but apparently did not. I don't even see a logical reason to believe that static typing precludes macros.

Where are the papers?

I do not know of any. Lisp-style macros are unfashionable these days.

Bear in mind that Paul Graham is a philosophy major who wrote a shopping cart in Lisp that was bought by Yahoo and subsequently rewritten. He struck gold, retired young and then spent years writing stuff like this.

Mistymisunderstand

2019 here, every single new language Julia, Nim, Haskell, Scala, Clojure, Elixir, Rust, D, C++ supports macros or some form of macros... – Mertiemerton

@aoeu256: C++ (1985), Haskell (1990), D (2001), Scala (2004), Clojure (2007) and Nim (2008) are all over 10 years old. Rust (2010), Elixir (2012) and Julia (2012) are new but Elm (2012), Typescript (2012), Purescript (2013), Swift (2014), Unison (2015), Reason (2016) and DarkLang (2019) are newer still and none support Lisp-style macros. C++ and D only provide C-style macros. Haskell and Scala don't really support macros: they just have experimental side projects. – Mistymisunderstand

@JD Scala 3 officially supports macros. – Wickerwork

Answer 4

Paul Graham is a proponent of having "the whole language there all the time":

There is no real distinction between read-time, compile-time, and runtime. You can compile or run code while reading, read or run code while compiling, and read or compile code at runtime.

Running code at read-time lets users reprogram Lisp's syntax; running code at compile-time is the basis of macros; compiling at runtime is the basis of Lisp's use as an extension language in programs like Emacs; and reading at runtime enables programs to communicate using s-expressions, an idea recently reinvented as XML.

So he may be referring to the practical impossibility of defining new types at runtime in a language that expects to have all the type information at compile time, as Daniel Ribeiro points out on his blog:

Note that you cannot make type-safe runtime metaprogramming in general. For instance: even though some languages allow you to create interfaces that do not exist on compile time, the only way to invoke methods from these is through non type-safe ways (such as reflection).

I am sure that you would have no trouble finding programmers who dispute that this capability is worth giving up the benefits that they derive from static typing.

Dissipated

Answer 5

Static typing, in which the system does not infer types, prevents truly general-purpose macros as the output of macros must remain type-safe in a very restrictive sense.

Consolata