For those curious about what Scala macros actually are:
"This facility allows programmers to write macro defs: functions that are transparently loaded by the compiler and executed during compilation. This realizes the notion of compile-time metaprogramming for Scala."
http://bit.ly/zeMjOb
Scala Macros: “Oh God Why?”
11–20 of 57 posts
Re: Scala Macros: “Oh God Why?”
#12Earlier quoted context omitted.
What else do you think macros provide? As a former professional Common Lisp dev, those two features strike me as the real difference between a macro and function call.
For Common Lisp, think also of reader macros. Similarly, in syntactically richer languages, macros could add syntactic constructs that are not akin to function application. With sufficiently powerful macros, you can add, for example, new infix operators, a new form of switch/case or a new way to declare variables.
Scala already has plenty of syntactic sugar for chaining method calls, so you can write stuff like:
myObj explode 10 times
which translates into myObk.explode.10.times()
Through the magic of implicits, you can make any builtin type auto-cast to your wrapper type, so there really is no need for syntactic macros - scala is already DSL-enabled.
Re: Scala Macros: “Oh God Why?”
#13I seems to be a rather common tension in open source projects developed by research institutions. The goal of users of those projects is immediate usability which clashes with goals of developers, research. I have some doubts where one can get PHD (publish an article with high citation index) by improving a compiler error messages. As opposed to adding a new cool feature to the language/compiler, cryptic error messag…
With respect to publishing, it depends on what conferences you target with your publication. For example, at the intersection of the software engineering and PLDI communities, you'll have quite a few researchers interested in proper tooling. ASE (Automated Software Engineering), for example, is a highly regarded conference that is really interested in this type of research.
There are also other incentives for researchers to create usable tools and implementations (assuming that the tools are actually meant to be more than experimental prototypes).
To begin with, compiler developers traditionally "dogfood" their compilers. They may still be willing to live with things that you wouldn't have in a commercial product, but they can't and don't completely neglect usability, either.
Second, usable tools are more likely to be adopted by other researchers, creating a positive feedback loop with respect to future publishing opportunities.
Re: Scala Macros: “Oh God Why?”
#14Earlier quoted context omitted.
For Common Lisp, think also of reader macros. Similarly, in syntactically richer languages, macros could add syntactic constructs that are not akin to function application. With sufficiently powerful macros, you can add, for example, new infix operators, a new form of switch/case or a new way to declare variables.
Scala already has plenty of syntactic sugar for chaining method calls, so you can write stuff like: myObj explode 10 times which translates into myObk.explode.10.times() Through the magic of implicits, you can make any builtin type auto-cast to your wrapper type, so there really is no need for syntactic macros - scala is already DSL-enabled.
I agree that Scala's excellent implicits, syntactic sugar, destructuring and other pattern matching indeed cover a great number of typical macro use-cases, but to say there is "no need" may be a little strong. http://scalamacros.org/usecases/ lists a number of improvements macros can bring over current Scala syntax for some operations.
Re: Scala Macros: “Oh God Why?”
#15I think many people share some concerns about macros, especially the need for good error messages. A far as I know Scala's language designers have been against including macros for a long time. So the proposal for macros has to be damn good if they change their opinion.
Macros are supposed to be a replacement for writing compiler plugins in many cases (compare with Java annotation processing vs. Java compiler plugins). The API is easier and more straightforward, semantics are easier to understand and don't require separate setup step.
In the meantime work has of course not stopped:
- Syntax has been simplified and several confusing bits have been removed/deprecated (Octal literals, FP literals without digit after dot, ...).
- The jar size of the library has been reduced, while adding fixes and functionality.
- Value classes have been integrated, which provide the performance of primitives with user-defined classes.
- Inlining has been improved a lot.
- Compilation speed has been improved a lot.
- Some collection classes have been performance optimized and are now a lot faster (and sometimes faster than the Java implementation).
- Play 2.0 and Akka 2.0 have been released, both with huge amounts of documentation.
- Documentation has been improved.
- ...
My personal impression is that while Scala has roots in academia, solving real-world issues is the focus of the team.
Re: Scala Macros: “Oh God Why?”
#16I'd like to single out this line from the linked article:
"Unlike Java, type signatures in Scala don’t really explain idiomatic usage to mortals very well."
This is a great diagnosis of one of the big issues with Scala's style of static typing. Everyone knows that the type descriptions take a bit to grok compared to a C-style languages. Why? Well, in C-style languages, a function definition is itself a representation of idiomatic usage. In Scala and its brethren, you have to translate from one to the other.
I'm sure that's a commonplace observation, but it had not jumped out at me like that before.
Re: Scala Macros: “Oh God Why?”
#17The bug in this post is thinking that if you have someone willing to contribute feature X to an open source project, they were also available to contribute feature Y.
Open source patches are all itch-scratchings. For Scala macros, it's a researcher at EPFL, I believe. I don't think you could write a thesis about fixing bugs in the IDE. So this contributor was not available to submit IDE bugfixes; they _were_ available to submit macros.
It's the same for other contributors. Someone building an app on Scala may be available to submit a fix for some scalability issue they are hitting in production; they will not be available to work on macros, or on IDE bugfixes.
Open source projects get the fixes they get. You can't act like the priorities are set by some central product manager.
So I think it's just not correct to argue that "the priorities are wrong, why are they doing this instead of that, etc." - everyone is doing what matters to them. Some people _are_ working on IDE bugfixes, other people are working on macros. People can do what they want.
Re: Scala Macros: “Oh God Why?”
#18Macros are useful in Scala. Mostly not for application developers, but for library or framework developers. It enables you to do things while keeping the typesafety nature that makes Scala so great.
In Play, we have generated code for forms validation and json serialization. This enables the compiler to see code that can't work, while a more dynamic approach would lead to an exception at runtime.
Re: Scala Macros: “Oh God Why?”
#19Where I work (i.e. write code for money, to satisfy Ted Nyman's requirement that my opinion matter), our reaction was exactly the opposite--we're very much looking forward to having macros in Scala.
If this was a more esoteric language feature, I'd be inclined to agree, but macros (if done well), I think will be a huge boon to the language.
I do all sorts of hackery in Java now (external code generation, heavily using annotation processing tools (APTs) which are a very, very limited form for language-based code generation) to do semi-metaprogramming stuff and can't wait to do the real thing.
(And do it well, e.g. not to make things "even more cryptic" just for the fun of it, but to solve real problems.)
Re: Scala Macros: “Oh God Why?”
#20The bug in this post is thinking that if you have someone willing to contribute feature X to an open source project, they were also available to contribute feature Y. Open source patches are all itch-scratchings. For Scala macros, it's a researcher at EPFL, I believe. I don't think you could write a thesis about fixing bugs in the IDE. So this contributor was not available to submit IDE bugfixes; they _were_ availabl…
Sure, but the communities behind all the FP languages seem to share this same weakness. For obvious reasons, they attract people much more interested in hacking on funky compiler techniques than on mundane things like I/O libraries and documentation.
In contrast, I think Python and Ruby both owe a lot of their success to the people willing to put a lot of energy and polish into this essential but less glamorous work.