Haskell 中的主函数总是以 main = do 开头吗？

Question

In java we always write:

public static void main(String[] args){...}

when we want to start writing a program.

My question is, is it the same for Haskell, IE: can I always be sure to declare: main = do, when I want to write code for a program in Haskell?

for example:

main = do  
    putStrLn "What's your name?"  
    name <- getLine 
    putStrLn ("Hello " ++ name) 

This program is going to ask the user "What's your name?" the user input will then be stored inside of the name-variable, and "Hello" ++ name will be displayed before the program terminates.

Answer 1

Short answer : No , we have to declare a main = , but not a do .

The main must be an IO monad type (so IO a ) where a is arbitrary (since it is ignored), as is written here :

The use of the name main is important: main is defined to be the entry point of a Haskell program (similar to the main function in C), and must have an IO type , usually IO () .

But you do not necessary need do notation. Actuallydo is syntactical sugar . Your main is in fact:

main =
    putStrLn "What's your name?" >> getLine >>= \n -> putStrLn ("Hello " ++ n)

Or more elegantly:

main = putStrLn "What's your name?" >> getLine >>= putStrLn . ("Hello " ++)

So here we have written a main without do notation. For more about desugaring do notation, see here .

Answer 2

Yes, if you have more than one line in your do block, and if you are even using the do notation.

The full do -notation syntax also includes explicit separators -- curly braces and semicolons:

main = do { putStrLn "What's your name?" 
          ; name <- getLine  
          ; putStrLn ("Hello " ++ name) 
          }

With them, indentation plays no role other than in coding style (good indentation improves readability; explicit separators ensure code robustness, remove white-space related brittleness). So when you have only one line of IO-code, like

main = do { print "Hello!" }

there are no semicolons, no indentation to pay attention to, and the curly braces and do keyword itself become redundant:

main = print "Hello!" 

So, no, not always. But very often it does, and uniformity in code goes a long way towards readability.

---

do blocks translate into monadic code, but you can view this fact as implementational detail, at first. In fact, you should. You can treat the do notation axiomatically , as an embedded language, mentally. Besides, it is that, anyway.

The simplified do -syntax is:

   do {  pattern1 <- action1
      ;  pattern2 <- action2
      .....................
      ;  return (.....)
      }

Each action i is a Haskell value of type M a i for some monad M and some result type a i . Each action produces its own result type a i while all action s must belong to the same monad type M .

Each pattern i receives the previously "computed" result from the corresponding action.

Wildcards _ can be used to ignore it. If this is the case, the _ <- part can be omitted altogether.

---

"Monad" is a scary and non-informative word, but it is really nothing more than EDSL, conceptually. Embedded domain-specific language means that we have native Haskell values standing for (in this case) I/O computations . We write our I/O programs in this language, which become a native Haskell value(s), which we can operate upon as on any other native Haskell value -- collect them in lists, compose them into more complex computation descriptions (programs), etc.

The main value is one such value computed by our Haskell program. The compiler sees it, and performs the I/O program that it stands for, at run time.

The point to it is that we can now have a "function" getCurrentTime (impossible, on the face of it, in functional paradigm since it must return different results on separate invocations), because it is not returning the current time -- the action it describes will do so, when the I/O program it describes is run by the run-time system.

On the type level this is reflected by such values not having just some plain Haskell type a , but a parameterized type, IO a , "tagged" by IO as belonging to this special world of I/O programming.

See also: Why does haskell's bind function take a function from non-monadic to monadic .