this post was submitted on 04 Dec 2023
4 points (100.0% liked)

Haskell

65 readers
3 users here now

**The Haskell programming language community.** Daily news and info about all things Haskell related: practical stuff, theory, types, libraries, jobs, patches, releases, events and conferences and more... ### Links - Get Started with Haskell

founded 1 year ago
 

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.

top 3 comments
sorted by: hot top controversial new old
[–] [email protected] 1 points 11 months ago* (last edited 11 months ago) (2 children)

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.

[–] [email protected] 1 points 11 months ago

@jaror

main = do putStrLn (cycle "buffalo " ++ !getLine)
[–] [email protected] 1 points 11 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.