Andres and Wouter interview Edwin Brady, most famous for his work on the Idris programming language. We talk about how he got interested in programming with dependent types, his thoughts on dependently typed programming in Haskell, and his vision for Idris.

  • jaror@kbin.socialOP
    link
    fedilink
    arrow-up
    1
    ·
    edit-2
    7 months ago

    I think Idris’ bang notation for performing effects in a do-block is pretty, it could look like this:

    main = do putStrLn ("You said: " ++ !getLine)
    
    

    Today, you’d have to come up with a new variable name or figure out the right combinator names:

    main = do line <- getLine; putStrLn ("You said: " ++ line)
    
    main = putStrLn . ("You said: " ++) =<< getLine
    
    

    But unfortunately there are more complicated cases:

    main = do print (True || !getLine == "foo")
    
    

    In a strict language with built-in short-circuiting logical operations the getLine would never be performed, but in Haskell || is just a normal function that happens to be lazy in its second argument. The only reasonable way to implement it seems to be to treat every function as if it was strict and always perform the getLine:

    main = do line <- getLine; print (True || line == "foo")
    
    

    Do you think this is confusing? Or is the bang notation useful enough that you can live with these odd cases? I’m not very happy with this naive desugaring.

    • Boyd Stephen Smith Jr.@hachyderm.io
      link
      fedilink
      arrow-up
      1
      ·
      7 months ago

      @jaror I never liked it; I think if you can’t be bothered to assign a name, point-free combinators are what you should be using.

      I also think it gets much uglier or complicated (or both) once you have arguments (unlike getLine, but like most subroutines).

      That said, I wouldn’t take it away from anyone. I think the desugaring is unsurprising and, at least in a strict language, semantics preserving.

      I haven’t really spent the necessary time to think clearly through the non-strict case.