Insure some examples compile

Author: coke

doc/Type/Signature.pod6

@@ -217,9 +217,9 @@ Normally, a type constraint only checks whether the value of the parameter is of
 correct type. Crucially, both I<object instances> and I<type objects> will satisfy
 such a constraint as illustrated below:
 
-    say  42.WHAT     # OUTPUT: «(Int)␤»
-    say  42 ~~ Int   # OUTPUT: «True␤»
-    say Int ~~ Int   # OUTPUT: «True␤»
+    say  42.^name;    # OUTPUT: «Int␤»
+    say  42 ~~ Int;   # OUTPUT: «True␤»
+    say Int ~~ Int;   # OUTPUT: «True␤»
 
 Note how both C<42> and C<Int> satisfy the match.
 
@@ -246,8 +246,8 @@ its L<DEFINITE|/language/mop#DEFINITE> method.
 
 To warm up, let's apply C<:D> to the right hand side of our humble C<Int> example:
 
-    say  42 ~~ Int:D  # OUTPUT: «True␤»
-    say Int ~~ Int:D  # OUTPUT: «False␤»
+    say  42 ~~ Int:D;  # OUTPUT: «True␤»
+    say Int ~~ Int:D;  # OUTPUT: «False␤»
 
 Note how only C<42> matches C<Int:D> in the above.
 
@@ -269,8 +269,8 @@ constraint, which checks whether the value passed is a type object
 rather than an object instance. Here's our C<Int> example again, this
 time with C<:U> applied:
 
-    say  42 ~~ Int:U  # OUTPUT: «False␤»
-    say Int ~~ Int:U  # OUTPUT: «True␤»
+    say  42 ~~ Int:U;  # OUTPUT: «False␤»
+    say Int ~~ Int:U;  # OUTPUT: «True␤»
 
 Now C<42> fails to match C<Int:U> while C<Int> succeeds.
 
@@ -288,6 +288,7 @@ Here's a more practical example:
 Calling C<can-turn-into> with an object instance as its second parameter
 will yield a constraint violation as intended:
 
+=for code :preamble< sub can-turn-into(Str $, Any:U $) {...}>
     say can-turn-into("a string", 123);
     # OUTPUT: «Parameter '$type' of routine 'can-turn-into' must be a type object of type 'Any', not an object instance of type 'Int'...»