evincarofautumn/InlineDoBind.md

## InlineDoBind.md

      
    Raw
  

              InlineDoBind.md
            
          
    Thoughts on an InlineDoBind extension

An expression beginning with a left arrow (<-) inside a do block statement is desugared to a monadic binding. This is syntactically a superset of existing Haskell, including extensions. It admits a clean notation that subsumes existing patterns and comes with few downsides.
Examples

do
  f (<- x) (<- y)
-- ===
do
  A <- x
  B <- y
  f A B
(Here, A and B are assumed to be fresh variables.)
Like applicative notation, this makes useless intermediate names easier to avoid, leading to code that’s more stable under certain refactorings, in the same manner as point-free style.
Moreover, desugared binds cannot refer to one another, because their bindings are not named. This plays very nicely with ApplicativeDo desugaring as a result.
do
  f (<- x) (<- y)
-- ===
join $ f <$> x <*> y
The greatest benefit is a natural inline style of binding without applicative operator soup.
do
  f (<- a) b (<- c) d
-- ===
join $ f <$> a <*> pure b <$> c <*> pure d
The common solution to this is to reorder the arguments of f to take the pure bindings first, in which case the applicative notation is more concise, but the inline-bind notation is comparable in size and more legible.
do
  f b d (<- a) (<- c)
-- ===
join $ f b d <$> a <*> c
It brings Haskell syntax closer to mainstream languages with things like async / await, as well as Go’s notation for channels.
do
  let (a1, a2) = (<- async (getURL url1), <- async (getURL url2))
  let (page1, page2) = (<- wait a1, <- wait a2)
  ...
-- ===
do
  A <- (,) <$> async (getURL url1) <*> async (getURL url2)
  let (a1, a2) = A
  B <- (,) <$> wait a1 <*> wait a2
  let (page1, page2) = B
  ...
Note that this doesn’t preserve the desirable property that let bindings are trivially known to be pure, because they may introduce monadic bindings before them.
Details

The desugaring relates expressions to their innermost enclosing do. So this:
do
  f (g (<- x))
-- ===
do
  A <- x
  f (g A)
-- ===
f . g =<< x
Is different from this:
do
  f $ do
    g (<- x)
-- ===
do
  f $ do
    A <- x
    g A
-- ===
f (g =<< x)
Therefore, do is given slightly more significance, leading to code that’s potentially less stable under certain refactorings such as motion/insertion/deletion of do blocks.
Desugaring proceeds from left to right, i.e., depth-first in the case of nested inline bindings:
do
  process (<- (<- getAction) (<- getArgument)) (<- getConfig)
-- ===
do
  Result <- (<- getAction) (<- getArgument)
  Config <- getConfig
  process Result Config
-- ===
do
  Action <- getAction
  Argument <- getArgument
  Result <- Action Argument
  Config <- getConfig
  process Result Config
It’s tempting to get too clever about this, allowing bindings to refer to one another, traversing things in different orders, &c. Don’t!
Expression statements and the right-hand sides of let and monadic bindings are all desugared.
do
  f (<- x)
  let g = h (<- y)
  i <- (<- z)
  return i
-- ===
do
  A <- x
  f A

  B <- y
  let g = h B

  C <- z
  i <- C

  return i
Note that the x <- y syntax is now equivalent to let x = <- y; x is equivalent to let _ = <- x.
Records within do blocks are desugared, too.
do
  return R { m <- x, n = f (<- y) }
-- ===
do
  A <- x
  B <- y
  return R { m = A, n = f B }
This skirts problems of legibility with the RecordWildCards solution of:
do
  m <- x
  n <- f <$> y
  return R{..}
It’s also far less ambiguous than similar proposals, such as idiom brackets.
The left arrow would be treated as a level-10 precedence expression, like \, let, if, case, and do. Otherwise, inline-bind expressions would be ambiguous with ordinary bind statements:
do
  f <- x
  ...
To use an inline bind, this must be written as:
do
  f (<- x)
  ...
-- ===
do
  f $ <- x
  ...