Opóźnienia z => ciąg dalszy ze scala.Predef

Kiedy pisałem Różne miejsca wystąpienia => w języku Scala nie sądziłem, że symbol implikacji w Scali będzie mnie tak prześladował. W komentarzu do tego wpisu, Grzesiek napisał "no daj spokój, deklaracja sposobu przekazania wartości parametru metody ma być znajomością Scali "na wyższym poziomie"?", a tu na wykładzie Lecture 3.5 w "Functional Programming Principles in Scala" pojawił się scaladoc dla scala.Predef z assert, w którym drugi argument jest message: => Any. Widzicie ten symbol implikacji => przy Any?

W ten sposób możemy oczekiwać jedynie wykonania wyliczenia komunikatu, kiedy assertion typu Boolean jest spełnione. Sprytne. To lubię! Sprawdź to sam!

$ sbt console
Welcome to Scala version 2.9.2 (OpenJDK 64-Bit Server VM, Java 1.7.0-u10-b09).
Type in expressions to have them evaluated.
Type :help for more information.

scala> def printMessage = println("Wykonano mnie")
printMessage: Unit

scala> printMessage
Wykonano mnie

scala> assert(true, printMessage)

scala> assert(false, printMessage)
Wykonano mnie
java.lang.AssertionError: assertion failed: ()
     at scala.Predef$.assert(Predef.scala:160)
     at .<init>(<console>:9)
     at .<clinit>(<console>)
     at .<init>(<console>:11)
     at .<clinit>(<console>)
     at $print(<console>)
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
     at java.lang.reflect.Method.invoke(Method.java:601)
     at scala.tools.nsc.interpreter.IMain$ReadEvalPrint.call(IMain.scala:704)
     at scala.tools.nsc.interpreter.IMain$Request.loadAndRun(IMain.scala:914)
     at scala.tools.nsc.interpreter.IMain.loadAndRunReq$1(IMain.scala:546)
     at scala.tools.nsc.interpreter.IMain.interpret(IMain.scala:577)
     at scala.tools.nsc.interpreter.IMain.interpret(IMain.scala:543)
     at scala.tools.nsc.interpreter.ILoop.reallyInterpret$1(ILoop.scala:694)
     at scala.tools.nsc.interpreter.ILoop.interpretStartingWith(ILoop.scala:745)
     at scala.tools.nsc.interpreter.ILoop.command(ILoop.scala:651)
     at scala.tools.nsc.interpreter.ILoop.processLine$1(ILoop.scala:542)
     at scala.tools.nsc.interpreter.ILoop.loop(ILoop.scala:550)
     at scala.tools.nsc.interpreter.ILoop.process(ILoop.scala:822)
     at scala.tools.nsc.interpreter.ILoop.main(ILoop.scala:851)
     at xsbt.ConsoleInterface.run(ConsoleInterface.scala:57)
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
     at java.lang.reflect.Method.invoke(Method.java:601)
     at sbt.compiler.AnalyzingCompiler.call(AnalyzingCompiler.scala:73)
     at sbt.compiler.AnalyzingCompiler.console(AnalyzingCompiler.scala:64)
     at sbt.Console.console0$1(Console.scala:23)
     at sbt.Console$$anonfun$apply$2$$anonfun$apply$1.apply$mcV$sp(Console.scala:24)
     at sbt.TrapExit$.executeMain$1(TrapExit.scala:33)
     at sbt.TrapExit$$anon$1.run(TrapExit.scala:42)

Pewnie domyślasz się, skąd ten wyjątek przy drugim wykonaniu? Niespecjalnie istotne w kontekście =>, ale znać, nie zawadzi.