[rebuttal] typo + redo detailed comments

icfp-2016/rebuttal.txt

@@ -36,8 +36,8 @@ Thanks!
      in section 2.
 
      Specific guarantees like "the new division function raises
-     compile-time errors when called with a 0 denominators" are theorems
+     compile-time errors when called with 0 denominators" are theorems
-     that may be stated and proven correct in the same was as Haskell's or
+     that may be stated and proven correct in the same way as Haskell's or
      ML's type system is proven correct.
 
      The examples are chosen precisely because they suggest theorems that a
@@ -49,121 +49,68 @@ Thanks!
 === END OF FORMAL RESPONSE. Detailed comments to reviewers (RA RB RC) follow.
 ================================================================================
 
---------------------------------------------------------------------------------
---- RA RB RC, re: purpose & organization of pearl
-
-   The pearl is currently organized as:
-
-      Section 1 : examples, design goals, outline of pearl
-
-      Section 2 : formalize intuition from Sec. 1,
-                  get readers thinking: "how could I do this in my language?"
-
-      Section 3 : motivating + useful + versatile examples
-
-      Section 4 : justify "annotation free" claim from Sec. 1
-
-      Section 5 : basics of Racket macros,
-                  full details of two examples from Sec. 3,
-                  how to handle definitions,
-                  checklist of useful Racket features
-
-      Section 6 : rekindle the fun of Sec. 1 after the long Sec. 5
-
-
-   With the reviewers' permission, we propose a different organization:
-
-     Section 1 : same as before
-
-     Section 2 : same as before
-
-     Section 3 : same examples,
-                 explicitly compare to Typed Racket without our library,
-                 list desirable guarantees of each elaborations
-
-     Section 4 : same as before
-
-     Section 5 : basics of Racket macros in terms of `printf`
-
-     Section 6 : internals of every example from Sec. 3
-                 emphasis on Sec. 3.6
-
-     Section 7 : checklist of useful Racket features
-
-     Section 8 : related work + implementation sketch for other languages
-
-     Section 9 : conclusion
-
-
 --------------------------------------------------------------------------------
 --- RA RB, re: translating the ideas to Typed Clojure, Scala, and Rust
 
   These languages have equally powerful syntax extensions as Racket.
-  The tools are just less mature / less documented.
+  The tools are just less mature and less documented.
 
   * Clojure's macros are arbitrary rewrite rules interspersed with
-     normal Clojure code run at compile-time.
+    normal Clojure code run at compile-time.
-    The main difficulty will be parsing complicated syntax patterns and
-     being robust against renamings.
 
-  * Scala Macros may not be able to handle definitions, but can
+  * Scala's Lightweight Modular Staging (LMS) [1] framework can implement
-     definitely handle type-safe printf for constant strings [2].
+    rewrite rules and compile-time partial evaluation. We believe it
-    Scala LMS [3] seems to be more powerful. Either way Scala's
+    can also simulate identifier macros; if not, Scala's compiler plugin API [2]
-     compiler plugins [4] are at least as powerful as Racket's macros.
+    definitely can.
 
   * Rust's macros cannot implement our interpretation functions, but
-     their compiler plugins [5] are on-par with Scala's.
+    their compiler plugins [3] are on-par with Scala's.
 
   Sources:
-    [1] https://github.com/clojure/tools.macro
+    [1] https://scala-lms.github.io/
-    [2] http://docs.scala-lang.org/overviews/macros/overview.html
+    [2] http://www.scala-lang.org/old/node/8656
-    [3] https://scala-lms.github.io/
+    [3] https://doc.rust-lang.org/book/compiler-plugins.html
-    [4] http://www.scala-lang.org/old/node/8656
-    [5] https://doc.rust-lang.org/book/compiler-plugins.html
 
 
 --------------------------------------------------------------------------------
 --- RA RB, re: (printf "~a")
 
    Calling (printf "~a") raises an arity error in our implementation because
-    "~a" is a valid format specifier yet `printf` is called with zero additional
+   "~a" is a valid format specifier yet `printf` is called with zero additional
-    arguments.
+   arguments.
    Calling (printf "~b") would give the same arity error.
+   These both compile in Typed Racket but fail at runtime.
 
-   But (printf "~a") is definitely a typo.
+   But writing (printf "~a") was a typo on our part.
    We intended to use "~s" instead.
-   (Both specifiers accept any value but format the result slightly differently)
 
    The final version of the paper will give actual error messages instead of
-    using ⊥.
+   using ⊥.
 
 
 --------------------------------------------------------------------------------
 --- RA, re: Dialyzer
 
-   The Dialzyer belongs in our discussion of related work --- either in the
+   The Dialyzer belongs in our discussion of related work.
-    intro or part of a dedicated section.
+   Its guarantee matches our third requirement for elaborations
-   Its guarantee matches our third requirement for elaborations (statically
+   (statically rejected programs will go wrong at runtime).
-    rejected programs will go wrong at runtime).
 
-   The PEPM'13 paper you mention is interesting, but orthogonal to our
+   The PEPM'13 paper is interesting, but orthogonal to our pearl.
-    pearl.
 
    - We are seeking to catch more runtime errors statically and allow more
-      dynamically-correct programs that fail to typecheck as written.
+     dynamically-correct programs that fail to typecheck as written.
-     Our strategy is to do so with local transformations.
 
    - Sagonas, Silva, and Tamarit are computing program slices to improve
-      the quality of type error messages.
+     the quality of type error messages.
 
-   But their technique would be very useful for Typed Racket
+   But their technique would be very useful for Typed Racket.
 
 
 -----------------------------------------------------------------------------
 --- RA, re: using #false in interpretations
 
    This was a careless error on our part.
-   Instead of `#false` we mean to use a unique sentinel value.
+   We meant to use a unique sentinel value.
 
 
 --------------------------------------------------------------------------------
@@ -171,31 +118,25 @@ Thanks!
 
    We removed casts around every call to `regexp-match` we found in typed code.
    But that was only 10 calls and unfortunately we found no typed programs
-    using SQL.
+   using SQL.
 
-   Besides removing casts, the library is also useful for early detection of
+   But aside from removing casts, the library is also useful for early detection
-    bugs when writing programs.
+   of bugs when writing programs.
-   Our personal experience has been good and we are currently in the process
+   Our personal experience has been good and we are currently soliciting
-    of soliciting feedback from Typed Racket users
+   feedback from Typed Racket users
 
 
 --------------------------------------------------------------------------------
---- RA, re: type error messages
+--- RA, re: the quality of type error messages
 
-   The error messages have been surprisingly good.
+   Compile errors raised by our implementation point out exactly what values
-   When we can immediately reject a program (due to out-of-bounds vector access,
+   caused the local transformation to fail. These are easy to read.
-    etc) we can give a specific error message and will show these in the
-    final version of the paper.
-   When deferring errors to Typed Racket, the error message has always been
-    triggered by a new annotation added to the original source code, so errors
-    are typically caught earlier than normal.
 
+   Type errors raised in post-elaboration code are (so far) caused by introduced
+   type annotations. These errors are concise, but could use more context.
 
---------------------------------------------------------------------------------
+   e.g. the error for (printf "~b" 3.14) says that 3.14 has the wrong type,
---- RA, re: small comments
+   but does not cite the format string "~b" as the reason why.
-
-   Thanks for showing us the Formatting package!
-   We thought Template Haskell was the Haskell programmers' only way to safety.
 
 
 --------------------------------------------------------------------------------
@@ -203,17 +144,20 @@ Thanks!
 
    gcc does indeed print a warning for invalid & mismatched format specifiers.
    It also complains when called on non-literal strings.
+   OCaml also catches printf type errors.
 
-   We will say "many" languages instead of "most".
+   We will say "many languages fail" instead of "most".
 
 
 --------------------------------------------------------------------------------
---- RC, re: examples "don't really drive the point home"
+--- RC, re: flow of Sec. 3
 
-   This is a weakenss of our presentation.
+   RC writes:
-   If permitted, we will reorganize to show how the examples run in Typed Racket
-    and compare to our library.
 
-   (Doing so is a little tricky, as some examples cannot be run in Typed Racket,
+       "The example calls ... don't really drive the point home.
-    others run with dynamic errors, and Sec. 3.6 requires an elaborate
+        I would have expected a couple of examples along the
-    work-around currently described in prose.)
+        following lines: here is what I have to write without the
+        system and here is what I can write using the system."
+
+   This is a weakness of our presentation.
+   We will clarify the problems solved by each example.