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.
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 (). (The name main is special only in the module Main; we will have more to say about modules later.)
A Haskell program needs to have an “entry point” called main . Normally, when we write Haskell, the order that we add stuff to a file doesn't matter. We can define functions and types in any order that we think of them.
The usual convention is to put them at the end of the script. And of course you can't call main before you define it.
in goes along with let to name one or more local expressions in a pure function.
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 themain
function in C), and must have anIO
type, usuallyIO ()
.
But you do not necessary need do
notation. Actually do
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.
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 actioni
is a Haskell value of type M ai
for some monad M
and some result type ai
. Each action
produces its own result type ai
while all action
s must belong to the same monad type M
.
Each patterni
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With