Scala Macros News

Half a year in macro paradise at Scala Days 2013

dev@scalamacros.org — Sat, 18 May 2013 00:00:00 PDT

Announced right before 2.10.0-final, macro paradise became the home for experimentation in the macro land. In this talk I will cover the ideas we played with and outline what panned out and what did not. What's going to happen to quasiquotes? Are type macros useful enough? Do macro annotations make sense? Come over and find out the answers.

Scala Days 2013 session page: http://www.scaladays.org/#/june-12/room1/10:15-11:00/Half-a-Year-in-Macro-Paradise

Evolution of Scala macros at Strange Loop 2013

dev@scalamacros.org — Sat, 18 May 2013 00:00:00 PDT

Let’s take a journey to the internals of Scala macros!

We will start off in the early days of macros in Scala and the initial design of def macros, which ended up in the production release of Scala 2.10. We will also take a look at the popular use cases and patterns characteristic for our macro system.

Afterwards we are going to learn about macro paradise, a spawning pool for the new ideas, and get acquainted with its inhabitants: type macros, untyped macros, inference macros, jitted macros and macro annotations. Then, in the next act our new friends will try to make it into Scala 2.11, only to be stopped by the keepers of the Scala typechecker.

The narration will culminate when in addition to discovering a threat coming from the new macros, we find out that Scala 2.10 is already infiltrated. After the two forces collide, the next generation of macros in born, having two faces: blackbox macros and whitebox macros.

The next generation of macros brings peace to the macroland, and happiness ensues. But in the meanwhile, far away in macro paradise, macro annotations are getting mature, planning to try their luck in 2.12…

Strange Loop 2013 session page: https://thestrangeloop.com/sessions/evolution-of-scala-macros

Let our powers combine!

dev@scalamacros.org — Mon, 22 Apr 2013 00:00:00 PDT

Compile-time metaprogramming has been proven immensely useful enabling programming techniques such as language virtualization, embedding of external DSLs, self-optimization, and boilerplate generation amongst many others.

In the recent production release of Scala 2.10 we have introduced macros, an experimental facility which gives its users compile-time metaprogramming powers. Alongside of the mainline release of Scala Macros, we have also introduced other macro flavors, which provide their users with different interfaces and capabilities for interacting with the Scala compiler.

In this paper, we show how the rich syntax and static types of Scala synergize with macros, through a number of real case studies using our macros (some of which are production systems) such as language virtualization, type providers, materialization of type class instances, type-level programming, and embedding of external DSLs. We explore how macros enable new and unique ways to use pre-existing language features such as implicits, dynamics, annotations, string interpolation and others, showing along the way how these synergies open up new ways of dealing with software development challenges.

Download the paper: Scala Macros: Let Our Powers Combine! (PDF, 187 Kb)

Macro annotations and call for ideas

dev@scalamacros.org — Tue, 19 Feb 2013 00:00:00 PST

Hello! Today I'd like to present our latest development - the ability to add new members to the classes being compiled from any location in the program. To be honest, that's quite a breakthrough, because it opens the doors to a whole bunch of features labelled under the "macro annotations" category.

Here's an example, which shows how easy it is to add members to classes in your project. At the moment, the introduceMember API can only append members to existing classes, but the news are bigger than just that. The implementation technique, which we finally figured out, will let us expose things like changeMember, removeMember, introduceCompanion or virtually whatever along these lines.

13:29 ~/Projects/Kepler_introduce-member/sandbox$ cat Macros.scala
import scala.reflect.macros.Context
import language.experimental.macros

object Macros {
  def impl(c: Context)(target: c.Tree, name: c.Tree, code: c.Tree) = {
    import c.universe._
    val Literal(Constant(targetType: Type)) = c.typeCheck(target)
    val Literal(Constant(methodName: String)) = name
    val Function(methodParams, methodBody) = code
    val method = DefDef(NoMods, TermName(methodName), Nil, List(methodParams), TypeTree(), methodBody)
    c.introduceMember(targetType.typeSymbol, method)
    c.literalUnit
  }
  def addMethod(target: _, name: String, code: _) = macro impl
}
13:29 ~/Projects/Kepler_introduce-member/sandbox$ cat Test.scala
class C
object Test extends App {
  Macros.addMethod(classOf[C], "foo", (x: Int) => x + 2)
  println(new C().foo(2))
}
13:29 ~/Projects/Kepler_introduce-member/sandbox$ scalac Macros.scala && scalac Test.scala && scala Test
4

By the way, this example also demonstrates untyped macros (be sure to take a look at the macro paradise doc if you've not been following the latest macro research - there are some goodies which haven't been covered on this site). Though I digress. The main focus today is introduceMember and the possibilities it enables.

Now here comes the question. Imagine you have a capability to shape your program at will. Want to have lazy parameters? Easy - declare an annotation that changes the signature of a method declaring your parameter and then postprocesses the body. Want to have customizable case classes? Easy again - rebind a system macro annotation to do something that you want, including creating custom methods and even creating/changing the companion object.

What would you do with this freedom? And how much freedom do you need? Let us know at dev@scalamacros.org or drop a line to the mailing list, and we'll be able to tune the design of future macros for your personal use cases!

Macro paradise

dev@scalamacros.org — Tue, 18 Dec 2012 00:00:00 PST

Simultaneously with the release of Scala 2.10.0-final, scheduled for the first week of January 2013, we're going to announce the availability of paradise/macros, a dedicated branch in our official Scala repository which will host the latest macro developments.

When things like macro types, macro annotations or type inference-friendly macros - you name it - get ripe for beta testing, they are going to end up in paradise/macros. Much like the vanilla Scala, macro paradise is going to be built nightly and have its own Maven artifact, so it'll be very easy to use it in your projects.

In this talk I present a couple of new features that will be released into paradise this Christmas, along with a glimpse of the things to come. I also discuss the roadmap of macro development for the near future, so if you want to have something in Scala macros, be sure to take a look and speak up.

Screencast: http://vimeo.com/user8565009/macro-paradise-talk
Slides: http://scalamacros.org/talks/2012-12-18-MacroParadise.pdf
Discussion: http://groups.google.com/group/scala-language/browse_thread/thread/21c0cdce38715771

Status update

dev@scalamacros.org — Mon, 05 Nov 2012 00:00:00 PST

It's been two weeks since we published Scala 2.10.0-RC1, and it looks like the final release of 2.10.0 is coming really soon. So let's retrospect a little.

State of the art

Macros are now officially a part of the Scala language, albeit an experimental one. We have a decently working implementation and some docs (also much more docs are on the way - be sure to check the reflection guide and the macro guide at the Scaladoc site once they're up in a few days).

And what's the most important: we have several projects that already use macros, and even more are on their way. Here we'd like to take time and say a big and hearty "thank you" to our early adopters. You guys are fantastic!

Speaking of evolution, at first we imagined that macros would mostly deliver a convenient way to build DSLs or even language workbenches (that's why DSL-related use cases originally had such priority at http://scalamacros.org/usecases/index.html).

But later this perception has changed. Sure one can design much more powerful DSLs than it's possible without compile-time metaprogramming (e.g. literals for binary numbers or a LINQ-like DB connectivity toolkit). But we've mostly seen people using macros to perform low-level AST twiddling (which I think can't be classified as DSLing).

For example, there's an elaborate assert macro, a series of method inlining macros, a dynamic trait mixing macro (I know, that's my own Stack Overflow answer, but I've seen other people doing similar things as well), a macro which infers Scala types from database, a macro which generates json serialization type classes, also another serialization macro, et cetera et cetera. There's a bunch of other usages to achieve little improvements here and there (e.g. a macro that works around Scala closure conversion for better serialization), but we don't have source code to link for those. But anyways macros are still very useful for DSLs. In this department the biggest players to our knowledge are Slick, ScalaMock v3 and SBT v0.13.

Future avenues

Now while the post-release dust is settling, we're planning our next journey along the road of compile-time metaprogramming in Scala.

Our biggest interest lies in experimenting how language features such as types, implicits or annotations work together with macros. Currently macros can only work in the small, providing intra-method code generation, but with type macros, implicit macros and annotation macros it becomes possible to do stuff that transforms the very fabric of the language.

There are already designs of a theorem prover interface and an effect-capturing system that can be built on top of the new flavors of macros. We also have some sketches already outlined on this site (http://scalamacros.org/future.html), but expect more information to come over the next months.

Despite having new and shiny things to research, we definitely do not plan to abandon the freshly implemented functionality. Our macro- and reflection-related issue tracker is only slightly over 100 bugs and improvement suggestions. We dare you to double this amount!

On a more serious note, we're well aware of the limitations of the current macro system (separate compilation, awkwardness in scenarios the involve untyped or partially typed trees). There are some ideas how to overcome these hurdles, and we plan to look into these ideas as we go.

Putting it in a nutshell

Download the freshly released Scala 2.10.0-RC1, get started using our documentation, explore the macrology together with us and have fun! We hope you'll like macros - the incarnation of compile-time metaprogramming for Scala.

Research projects

dev@scalamacros.org — Mon, 05 Nov 2012 00:00:00 PST

It's this time of the year at EPFL. We sit down together and come up with the research projects we'd like to propose to our students and to the entire Scala community. This fall our list is rich on macro-related ideas, which are listed below. For the full list of the projects offered by our lab refer to http://lamp.epfl.ch/teaching/projects.

Optimizing collections with macros

High-order functions such as map, filter and foreach provide a very convenient way to work with collections, but this convenience often comes at a cost of performance. Typical use cases for collection processing involve anonymous functions, which usually compile down to JVM anonymous classes introducing noticeable runtime overhead.

With the advent of macros in Scala 2.10, the programmer can control how exactly the compiler is compiling invocations of given methods. By declaring collections methods as macros, it becomes possible to transform their usages into plain while loops, bringing the performance back to normal.

Within this project your work will be to: 1) devise a mini-benchmark to measure the state of the art performance of collections, 2) rewrite popular collection methods as macros, 3) assess the performance improvements.

A further extension to the project baseline is collection operation folding. It is quite common to see code like: list zipWithIndex filter { case (cls, idx) => … } map (_._1) which creates a new collection at each operation. It would be great if we could fuse the operations into a single one. This wouldn’t work if the partial result is stored in a variable, but many invocations are just one-liners which perform all the operations one after the other.

Offered by Eugene Burmako.

Using reified types for specialization

Generic code increases programmer productivity as it increases code reuse. For example, the LinkedList abstraction can be used in many contexts, from storing a list of numbers to storing representations of files on the disk. Unfortunately this comes at the expense of performance, as the generic code needs a common representation for all types. The common representation is usually a pointer to heap data. But for value types, such as integers, bytes and even value classes (see SIP-15) this leads to significant overheads, as they need to be allocated as objects on the heap and then pointed to, breaking data locality and adding an extra indirection.

To overcome this performance loss, many programming languages and virtual machines perform code specialization, which creates a copy of the generic class for each value type and adapts the data representation.

Scala does not require type parameters to be known at compile time, thus allowing truly-generic code to be generated. In this case, type information is not necessary and will not available in the generated bytecode. But this prohibits programmers from using specialized code from generic code, which might be desirable.

Scala can overcome the loss of type information in generic classes by attaching types in so-called ClassTags (formerly known as Manifests). This information can be used to dispatch to the correct specialized class implementation, and can be made either as a compiler plugin or as a macro. Either implementation is fine, as long as the syntactic overhead is reasonable. For this project one should research what is the best implementation and prepare a set of benchmarks that clearly show the performance hit of dispatching based on the ClassTag.

Offered by Vlad Ureche.

Macro-based class system

One of the important techniques enabled by compile-time metaprogramming is modular language extensibility. With macros, functionality that is typically provided as a hardcoded set of language features can be introduced piece-wise, as a part of the standard library. This is applicable even for such a fundamental functionality as class system [1].

For this project you will: 1) define a baseline subset of Scala that would be used to host the class system, 2) implement a macro-based desugaring which maps object-oriented concepts onto the baseline (an example of such a desugaring can be found in [2]).

The project is especially interesting in the context of the dependent object types research [3], which aims to provide a foundation of Scala. Macros can separate the core calculus of DOT from the rest of the language, keeping the heart of the language pristine.

References:
[1] Scheme with Classes, Mixins, and Traits http://www.ccs.neu.edu/racket/pubs/asplas06-fff.pdf
[2] Types and Programming Languages http://www.cis.upenn.edu/~bcpierce/tapl/
[3] Dependent Object Types, Towards a foundation for Scala’s type system http://lampwww.epfl.ch/~amin/dot/fool.pdf

Offered by Eugene Burmako.

Macro-based continuations

Starting with version 2.10, Scala features a lightweight alternative to compiler plugins - macros, which democratize compile-time metaprogramming. Several important problems such as code reification have already been solved with macros, and we’re continuously looking into ways to simplify the compiler by implementing its parts as macros and moving them into the standard library.

Continuations in Scala [1] are implemented by a series of type-directed transformations, which involve the typechecker and span two additional compilation phases. There is a conjecture that this logic can be packed into one or several macros, which gives rise to this project.

This project involves: 1) understanding how the CPS transform works currently, 2) devising a way to express non-local code rewritings with macros, possibly extending the current macro system, 3) implementing the CPS transform with macros.

References:
[1] Implementing First-Class Polymorphic Delimited Continuations by a Type-Directed Selective CPS-Transform http://lampwww.epfl.ch/~rompf/continuations-icfp09.pdf

Offered by Eugene Burmako.

Multi-stage programming with macros

Multi-stage programming (staging) [1] is a promissing aproach for developing high-performance programs with a high-level programming model. LMS [2] (type-driven staging) complements staging with type-safety and modularaity through the use of abstract data types. This approach is great for library/DSL developers but library/DSL users often face complex type errors that are hard to understand.

This project aims to use metaprogramming with Scala macros to provide simple interface for library/DSL users while giving the full abstract data type approach to library/DSL developers. Each LMS program will be pre-processed with a macro that replaces method calls with their DSL representatives. This will allow simple type checking (without abstract types) and thus improve the interface for numerous DSLs. Additionaly the macro will analyze static methods imported into the DSL and try to convert them into the DSL representation. For example, calling `Math.pow(x, 3)` will be automatically imported into the DSL if its interface allows for all its building blocks.

References:
[1] Multi-stage programming: http://www.cs.rice.edu/~taha/MSP/
[2] Lightweight Modular Staging: A Pragmatic Approach to. Runtime Code Generation and Compiled DSLs http://infoscience.epfl.ch/record/150347/files/gpce63-rompf.pdf

Offered by Vojin Jovanovic.

Interpreter for abstract syntax trees

Macros introduced in Scala 2.10 can be viewed as compiler plugins, but unlike full-fledged compiler plugins, they are much more convenient to write and maintain. This makes metaprogramming in Scala accessible for a wide range of users, increasing the number of programming problems that can be solved in a concise and maintainable way.

Yet there are still some hurdles that make metaprogramming in Scala more complicated than it should be. The most annoying of these obstacles is the separate compilation restriction, which requires macro implementations and macro usages to be compiled separately. This restriction is reasonable, because to call a macro implementation during compilation, that implementation must be in executable form. Nevertheless it’s possible to do better.

Scala compiler represents programs (including macro implementations) as abstract syntax trees, which go through the compilation pipeline and eventually end up as executable Java bytecodes. The idea of this project is to shortcut the path from trees to executables by writing an interpreter.

Your tasks in this project will be to: 1) determine whether the entire Scala language can be faithfully interpreted, 2) implement the interpreter and hook it into the macro engine, 3) evaluate the performance of interpretation in comparison with the performance of compiled code.

Offered by Eugene Burmako.

Updated the documentation

dev@scalamacros.org — Sun, 29 Apr 2012 00:00:00 PDT

I have just updated documentation for macros. It now features a getting started example and a reference of macro context and reflection API.

The documentation also features my recent talk about metaprogramming in Scala 2.10. Be sure to take a look, because the slides not only describe trees, symbols and types - three core data structures of Scala compiler, but also suggest a few tricks that make it easy to explore compiler's inner workings and find out necessary information by yourself.

Metaprogramming talk

dev@scalamacros.org — Sat, 28 Apr 2012 00:00:00 PDT

Redirecting to /talks/2012-04-28-MetaprogrammingInScala210.pdf

Scala Days 2012 talk

dev@scalamacros.org — Wed, 18 Apr 2012 00:00:00 PDT

Redirecting to /talks/2012-04-18-ScalaDays2012.pdf

Macro SIP released

dev@scalamacros.org — Fri, 09 Mar 2012 00:00:00 PST

Redirecting to https://docs.google.com/document/d/1O879Iz-567FzVb8kw6N5OBpei9dnbW0ZaT7-XNSa6Cs/edit?hl=en_US

Macro annotations

dev@scalamacros.org — Tue, 15 Nov 2011 00:00:00 PST

I'm excited to announce that we've decided to introduce a third flavor of macros into project Kepler, namely: macro annotations. These macros are very much inspired by Nemerle, but there are some important differences.

In line with the idea of transparent embedding into the language, macro annotations look the same as regular annotations, but instead of being static participants of the compilation, they trigger AST rewriting. As of such, macro annotations are expanded strictly after all other macros applicable to the annottee (e.g. macro annotations for a class kick in after all macro types get expanded and after the entire inheritance chain is resolved and the members are mixed in).

We have also played with the idea of macro annotations affecting outer scopes as well. For example, if we put a @lazy macro annotation on a parameter of some method def m(@lazy x: T), then we'd really like the annotation to overwrite the entire method. However, it's not perfectly clear how far upwards we should go (e.g. it might also be reasonable to wish that a member annotation rewrites the entire class), so we decided to do away with this idea for the moment.

Later today or tomorrow I will update the site with examples and further details about macro annotations. Stay tuned and let us know what you think at dev@scalamacros.org.

Seven use cases added

dev@scalamacros.org — Fri, 11 Nov 2011 00:00:00 PST

To be honest, this site, created a few days ago, wasn't intended for going all public right off the bat. Instead, I planned to gradually improve the content and then release it without hassle.

As you can guess, it was a complete surprise for me to hear from Tiark that the site has been mentioned on Hacker News. My first thought was: "Omg, I didn't have the time to write about use cases for macros". And rightly so - the very first comment pointed that "thing that bothers me is the empty 'Use cases' page. Scala macros might be a solution to a problem nobody has". Oh, dear, what a shame!

That's why I tried hard to put up several use cases that I've gathered during the last few months of conversations about macros. I hope that this will alleviate possible misunderstandings that have arisen.

In any case, thanks for your feedback, folks - it's very inspiring to know that project Kepler has found its audience right after the inception!

Talk at scala.by meetup (Russian)

dev@scalamacros.org — Sat, 29 Oct 2011 00:00:00 PDT

Redirecting to http://habrahabr.ru/blogs/scala/131919/

Status update and call for feedback

dev@scalamacros.org — Tue, 18 Oct 2011 00:00:00 PDT

My today's talk at the Scala meeting was about concrete ideas of bringing the notions of compile-time metaprogramming to Scala. The slides covers such fancy beasts as macro defs, macro types and even macro annotations. This is highly experimental and, definitely, not everything will make it into a Scala improvement proposal, but take a look and share your thoughts: read slides from today's talk.

During this month I've received a lot of very useful feedback. Say, Chris and Stefan want to experiment with LINQ-flavored facilities for Scala. They need reification, composability of queries, static checking/optimization of queries and transparency for the user. After a couple of discussions, we've come up with several ways of doing all that stuff with macros in a win-win fashion.

Also, for instance, Greg and Nada routinely have to bite the bullet and deal with gazillions of overloads that cover all those countless FunctionN and TupleN classes for their Scala to JavaScript crosscompiler. No problem, macros come to the rescue. After a brainstorming session, the draft of the proposal now features a way to generate tedious code with macros.

I'm hinting that at this very phase your feedback is priceless and has the possibility to significantly affect the design of Scala's macro system. Got a compelling use-case that can be simplified by macros? Just drop me a line in the comments here or to my email (see my profile or google for my name). I don't even have a beta version of macro-related Scala improvement proposal yet, so it would be very use to adapt macros to your personal use-cases. Looking forward to your comments!

Updated project goals for this fall

dev@scalamacros.org — Sun, 02 Oct 2011 00:00:00 PDT

My previous plans involved slowly starting with quasiquotations and gradually proceeding further, however, an unexpected event turned everything upside down.

Apparently, Stefan Zeiger and Christopher Vogt will be working at LAMP/TypeSafe starting from this October, and they are going to participate in a joint fun project of implementing LINQ for Scala. What a stunning use-case for macros! Would be really awesome to roll something working asap.

Splicing

dev@scalamacros.org — Wed, 28 Sep 2011 00:00:00 PDT

The journey to macroland keeps amazing me!

Take splices. At first they seemed just a clever response to AST composability issue. Then I figured out that splices can be used to drastically simplify pattern matching. But even that didn't exhaust the bag of tricks provided by splices!

A few days after the pattern matching revelation, I learned how schemers use ellipses to write declarative syntax transformers. Say, we want to code up the following syntactic transformation: (let ([var val] ...) body) = ((lambda (var ...) body) val ...). Clear and concise, but imagine how ugly this will become when we'll try to transform this informal notation into executable code.

This problem has been addressed by Eugene Kohlbecker, a researcher from Scheme community. He extended the macro system to literally understand those ellipses:

(define-syntax my-let
  (syntax-rules ()
    ((my-let ((var val) ...) body)
      ((lambda (var ...) body) val ...))))

Talk at Scala meeting

dev@scalamacros.org — Tue, 27 Sep 2011 00:00:00 PDT

Today I gave a talk about macros at Scala meeting. The slides start with a basic example of a compiler macro, proceed with more advanced stuff from macrology and conclude with project ideas: read slides from today's talk.

Epiphany about quasiquotes

dev@scalamacros.org — Tue, 20 Sep 2011 00:00:00 PDT

Quasiquotes do not have to conform to the syntax rules of the host language. In fact, they can be written in arbitrary style, as long as this style somehow exposes antiquotation facilities.

With such quasiquotes one can, say, concisely implement type-safe regexes or easily express peephole optimizations. Read more on that in "Why It’s Nice to be Quoted: Quasiquoting for Haskell".

Macros in a typed language with syntax: state of the art

dev@scalamacros.org — Sun, 18 Sep 2011 00:00:00 PDT

Today I've read two fundamental papers on Nemerle macros: "Syntax-Extending and Type-Reflecting Macros in an Object-Oriented Language" (referred to as "the thesis") and "Язык Немерле, часть 5" (referred to as "the article", sorry, folks, it's in Russian). Also I had a fruitful conversation with VladD2, the principal developer of Nemerle (kudos, Vlad, for your desire to help and very detailed explanations). Some preliminary findings:

1) Quasiquotation is very elegant. It only takes three intuitive language constructs (quotation, antiquotation, splicing, see the section 8.3 of the thesis for the summary and the section "Квази-цитирование" of the article for the details) to significantly simplify parsing and generation of abstract syntax trees. I was especially impressed by the usage of antiquotes and splices together with pattern-matching. Personally for me, the beauty of quasiquotations is especially striking after the troubles with composability of LINQ expression trees.

2) However, there's a painfully familiar problem with LINQ that still persists. How do we lift (i.e. transform to an AST) code from the outer world? Staging adepts take it easy - they lift all functions and values that have staged types (explicitly in tagful style or implicitly in tagless style, see the previous link to find out what this means) and ignore everything else. This comes at a price of syntactic overhead of extra typing (pun intended) + potential performance degradation due to possibly tagful AST representation (take a look here for more details), though the interop with the outer world is kinda ok. With macros we have to bite the bullet - in most cases one needs explicit antiquotations, and this imposes overhead at every callsite that references external code that one wants to lift. There's also a non-obvious dilemma of whether we allow macros to see values from their definition scopes (see the section 2.3.3 of the thesis).

3) Also it's completely unclear how to implement orthogonal codegeneration via macros in a statically typed OO-language. Firstly, macros most likely need to be moved to a separate unit of compilation. Secondly, when writing a macro we have a choice: to bear with untyped ASTs and have a possibility to generate new types, or to enjoy typed ASTs at the cost of locked typespace (don't even think about what happens if we add type inference to the mix). Thirdly, object-orientedness pours even more fuel to the fire since we get a completely heterogeneous concept of classes that do not compose with functions + there's inheritance. This all brings us to a classic nightmare familiar from stateful programming, when operations are randomly prohibited or allowed depending on the phase of the Moon. After all, it's not surprising that F# designers did not implement code generating macros and only went for read-only quasiquotations.

4) Regarding error messages and debugging for the code generated during macro expansion - it's not as bad as it seems. Along with generating executable code we can also generate surrogate source code for macro expansions (we do have an AST after all) which can be used to produce sane debug info. Of course, the original line numbers will be corrupted (yep, we can restore them with lenses, but stepping in the debugger will still be crazy) and there's a glitch with stack traces, but that's at least something, huh? Staging guys have much harder time here (e.g. see the slide #15 of the LMS presentation).

5) Moreover, it's desirable for macros in a language with syntax to have some control over the parser (e.g. see the section 6 of the thesis and also the "Genuine, Full-power, Hygienic Macro System for a Language with Syntax" tech report). This enables the programmer to implement such useful thingies as custom modifiers for declarations (think, "async method" or "method ... precondition ...") or even completely new syntactic constructs. Frankly speaking, this is useful, but not mandatory: the prior can be implemented with annotations that trigger macros for their annotees, while the latter is kinda already in Scala (e.g. see the canonic implementation of the "while" loop).

All in all, at the moment the concept of macros in mainstream programming languages looks to me like a weird mix of butterflies, unicorns, spiders and worms. Template Haskell, here I come.

Announcement at scala-user

dev@scalamacros.org — Sat, 17 Sep 2011 00:00:00 PDT

Redirecting to http://groups.google.com/group/scala-user/browse_thread/thread/800353f4a9ce36b9