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
The author doesn't even know what macros are: "I understand macros to provide two things (1) forced code in-lining and (2) a kind of non-strict semantics or lazy evaluation of arguments"
The other difference is (of course) what the macro returns - more code to be compiled, which enables things like binding of new symbols/types/etc. The most important part is that the generated code is adjacent to user code, so the two are lexically coupled. But in CL land, you probably take the codegen for granted and the lexical coupling doesn't matter as much.
Although, Scala specifically, I ran away from. The language itself isn't terrible, it just forces one to confront the endgame of the bankrupt Java philosophy. The stdlib is basically the cross product of pre-optimized category theory with noun-hell, and idiomatic scala is far too overabstracted through abuse of first-class modules (which, admittedly, was a design goal).
I tried to use the JVM for a long time, I really did. I thought the advantages of multiple implementations, platform flexibility, and a common type system were fantastic. The fundamental problem is that no matter the skin, when you want to peek through the abstraction you're still fundamentally writing Java. I absolutely detest the Java language itself, as it's basically what should come out of a compiler, not be fed into one (I realize this criticism is about 15% unfair given that Java did actually introduce some new concepts to mainstream programming but implemented them in the VM rather than the compiler, but it has really failed to keep up with the times).
At this point if I were using the JVM, it would most likely be to make use of some hypothetical damn good libraries. In that case, as I'd be gluing together things that are already typed, I'd use whatever dynamic language seemed prudent. The Java type system is an everpresent fact of life on the JVM, and I'm now of the opinion that trying to use a second type abstraction concurrently is foolish (especially if one wants to run their code on anything other than Hotspot). I think Clojure is an amazing piece of work, and would still be using it, but its lack of importance on typed data structures really kills my ability to reason while developing new abstractions (the lack of well-supported algebraic data types and pattern matching especially). Taken together, those last two points imply that a statically typed JVM language has to utterly commit itself to the Java type system. If I absolutely needed to write a library on the JVM, I would look into and most likely go with Ceylon/Kotlin (or Gosu if they ever actually did a source release), but failing those probably write java-in-kawa for the straightforward class definitions with macros to ease the pain.
In any case, I'd be damn certain of exactly what I was writing beforehand. The Java ecosystem is absolute garbage for prototyping.
Scala already has @inline and call-by-name, so it doesn't need macros for either purpose.
Macros in Scala are primarily of interest for metaprogramming; it's a fairly natural direction for Scala to take, given that Scala has always positioned itself as a language that supports internal DSLs.
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.
My experience has been that these features are great but not free. I often have to choose between writing expressive, elegant, DRY code that is mind-numbingly slow or writing Fortran in Scala. Much of the time our needs are better met by writing Fortran in Scala, but with a macro system it would at least be DRY Fortran.
Is that supposed to be a serious question? Of course Nevada has stoplights. There are nearly two million people in the Las Vegas area and around two hundred fifty thousand people in the Reno/Sparks area. Then there are LOTS of smaller towns with populations as low as twenty five up to fifty thousand. Sure there are huge amounts of unpopulated or sparsely populated areas but that's not much different than the central valley in California as an example.
Boom - it wasn't serious! It was meant to spark discussion on how on earth do these cars handle trickier aspects of driving on unmodified grids, such as traffic lights.
I would assume since they've already logged lots of hours driving around CA that the various sensors and cameras can already detect traffic lights. On that same line of thought I'd love to know how they adjust for speed in construction zones with non standard speed limit signs, the randomness of other drivers etc.
http://scalamacros.org/usecases/index.html