Scala Adding Macros to the Language

http://www.infoq.com/news/2012/07/scala-macros

by DanielRibeiro • 14 years ago

53 27 14 years ago

tsm3• 14 years ago

This gives me an all-new appreciation for Lisp. It's nice to use standard list operations in a macro instead of needing to learn AST magic.

jjm2• 14 years ago

+1 on the sentiment though I'm not fully understanding why this would be useful for me...

To me this is like a crutch that the language itself cannot solve.

Ultimately, Scala will be held back because of Java. Scala deserves to live on by itself.

tsm3• 14 years ago

What I'm saying is that in Lisp it feels like a natural part of the language. There's not a big leap from:

    (defun add-two (x) (+ 2 x))

to:

    (defmacro add-two (x) `(+ 2 ,x))

(And much more complex macros are still readable if you know the rest of the language.)

Whereas in Scala the macro facility looks different enough from vanilla code to have to be learned separately.

ShardPhoenix• 14 years ago

Java is the reason that Scala has had any significant interest at all.

chimeracoder• 14 years ago

> This gives me an all-new appreciation for Lisp.

I'm a Lisper who's also programmed in Scala. (And for the record, I'm not a Lisp purist - in fact, there are a number of things I really like about Scala).

But I'm not sure how I feel about this change. Scala can already implement things like DSLs through creative use of type inference, etc.

> It's nice to use standard list operations in a macro instead of needing to learn AST magic.

The power of Lisp's macros come from it's homoiconicity, which is something I could never have appreciated before learning Lisp - in fact, I didn't even understand its significance until I wrote an implementation of a Lisp compiler for the first time. (For the record, it was a better learning experience than it was a compiler, but that was the whole point).

The best explanation I've seen of homoiconic macros is one written by a well-known Perl programmer. http://lists.warhead.org.uk/pipermail/iwe/2005-July/000130.h... (In a way, it makes sense that a Perl programmer would be the best at explaining what homoiconicity is, given that its extreme heteroiconicity is the underlying cause of many of the common criticisms of Perl to begin with).

That email is mostly accurate, and it includes this gem:

> Source code generation is unreliable and inadvisable in every language except Lisp.

This is where macros really shine. Macros allow you to generate source code reliably - or put another way, they let you refactor your code far more than you ever thought possible. (When you realize how easy it is to write Lisp programs that recursively define other valid Lisp programs, it's not hard to see why it's such a favorite of the AI community![1])

But here's the catch - for the kind of reliability that MJD talks about, you need to have the internal representation of the language be a fundamental data structure in the language, not just the textual representation.

Why's that? It's simple:

> It's nice to use standard list operations in a macro instead of needing to learn AST magic.

In Lisp, the internal representation is a list. The AST is a list. There's no 'instead of' here... macros are simply AST magic made simple....!

[1] http://en.wikipedia.org/wiki/Technological_singularity

gruseom3• 14 years ago

The best explanation I've seen of homoiconic macros is one written by a well-known Perl programmer. http://lists.warhead.org.uk/pipermail/iwe/2005-July/000130.h...

Thank you for that - I enjoyed reading it.

Also, is that our btilly?

cageface• 14 years ago

When you realize how easy it is to write Lisp programs that recursively define other valid Lisp programs, it's not hard to see why it's such a favorite of the AI community!

I think Lisp's success in early AI work had as much to do with its support for higher order functions, repl, dynamic dispatch etc as it did with the macro facilities. Lisp was way ahead in those respects.

But you don't see nearly as much use of Lisp in AI now that many other languages have learned all of Lisp's tricks except homoiconicity and that a lot of "AI" in the field these days is really statistics and linear algebra.

Dn_Ab2• 14 years ago

When you realize how easy it is to write Lisp programs that recursively define other valid Lisp programs, it's not hard to see why it's such a favorite of the AI community!

I don't know what counts as "AI" anymore but in the Machine Learning community, it looks like Matlab, R, Python and Java dominate in terms of use and cutting edge packages. This is due to two things: modern ML does not focus on areas where Lisp gives a clear advantage and 2) what everyone else is using and reduced learning overhead are most important in determining favorites.

bad_user• 14 years ago

     But I'm not sure how I feel about this change. 
     Scala can already implement things like DSLs through
     creative use of type inference, etc.

The way I see it:

(-) there are some god-awful DSLs available for Scala ; the presence of a macros system would allow the reuse of syntax instead of coming up with operators that look like random noise

(-) LINQ becomes possible - I don't know how many people here used LINQ, but it's really awesome to express a query in terms of filter, map and flatMap, and depending on the underlying collection to issue a database query or to submit some code to the GPU for processing.

And LINQ is an instance where static typing really shines.

IsTom• 14 years ago

Yeah, it's the reason why Template Haskell (macros) are awkward. The ASTs are just too complicated.

zura• 14 years ago

Well, it is because you write AST in Lisp :)

bascule• 14 years ago

I hear they're adding dynamic typing to Haskell: http://www.infoq.com/news/2011/04/erlang-copied-jvm-and-scal...

dons• 14 years ago

Haskell has had macros and the Dynamic type since 2002.

mooism2• 14 years ago

Can we confine the April Fool's stuff to 1st April please.

HillOBeans• 14 years ago

I am suspicious that this is an attempt to make Scala more Clojure-like...

pohl• 14 years ago

It's not. If I remember right the did some big refactoring of the compiler and found some places where this macro facility made that work less verbose.

http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2012/Ref...

It's been a while since I watched this talk, so I may have the details wrong. It's a great talk, but at least read the abstract:

Reflection and compilers do tantalizing similar things. Yet, in mainstream, statically typed languages the two have been only loosely coupled, and generally share very little code. In this talk I explore what happens if one sets out to overcome their separation.

The first half of the talk addresses the challenge how reflection libraries can share core data structures and algorithms with the language's compiler without having compiler internals leaking into the standard library API. It turns out that a component system based on abstract types and path-dependent types is a good tool to solve this challenge. I'll explain how the "multiple cake pattern" can be fruitfully applied to expose the right kind of information.

The second half of the talk explores what one can do when strong, mirror-based reflection is a standard tool. In particular, the compiler itself can use reflection, leading to a particular system of low-level macros that rewrite syntax trees. One core property of these macros is that they can express staging, by rewriting a tree at one stage to code that produces the same tree at the next stage. Staging lets us implement type reification and general LINQ-like functionality. What's more, staging can also be applied to the macro system itself, with the consequence that a simple low-level macro system can produce a high-level hygienic one, without any extra effort from the language or compiler.

Scala Adding Macros to the Language

Related Stories