Commits on Nov 11, 2018

1. Allow function application on the right side of fast pipe. …

   Fast pipe desugars to |. Why? It's easy stub-able like: let (|.) = (a, f) => f(a);
   This results into the rhs of -> not taking function application to make this work:
   a->f(b) is parsed as (a->f)(b).
   The fact that there isn't function application on the rhs, has resulted
   into a wide range of problems with fastpipe.
   In printing you actually want the layout to break as if
   there was a function application on the rhs! The printing problems were
   fixed at the cost of a tremendous amount of complexity in the printer.
   
   Are the semantics (evaluation order etc) identical when defined in user space like this, as opposed to ppx?
   
   No, they aren't…
   
   ```
   let fn1 = (~foo=?, ()) => 1;
   let fn2 = (~bar=?, x) => 2;
   
   /* Ok */
   fn1(~foo=1, ())->(fn2(~bar=2))
   
   /* Ok */
   fn1(~foo=1,()) |. fn2(~bar=2)
   
   /* Error: This expression has type int. It is not a function. */
   fn1(~foo=1, ())->fn2(~bar=2)
   
   /* Explanation */
   fn1(~foo=1, ())->fn2(~bar=2)
   
   /* this translates to: */
   fn2(1)(~bar=2)
   
   /* however, because `~bar` is optional, `fn2(1)` already produced a value. Therefore: */
   2(~bar=2)
   ```
   
   In retrospect, not having function application on the rhs was a terrible mistake.
   Fast pipe is all about function application in its current form.
   If it was done via ppx, then you wouldn't get the error in the example
   above.

   

   IwanKaramazow committed Nov 11, 2018
   Configuration menu

   • View commit details
   • Copy full SHA for 1dc2043
   • Browse repository at this point

   Copy the full SHA

   1dc2043 View commit details

   Browse the repository at this point in the history