Skip to main content

Home/ Haskell/ Group items tagged printing

Rss Feed Group items tagged

Javier Neira

A Neighborhood of Infinity: The IO Monad for People who Simply Don't Care - 0 views

  • Many programming languages make a distinction between expressions and commands.
  • Like other languages it makes the distinction, and like other languages it has its own slightly idiosyncratic notion of what the difference is. The IO monad is just a device to help make this distinction.
  • There is no room for anything like a print command here because a print command doesn't return a value, it produces output as a side-effect
  • ...18 more annotations...
  • It's easy to use: you just write do and then follow it by an indented list of commands. Here's a complete Haskell program:
  • Note also that commands take arguments that can be expressions. So print (2*x) is a command, but 2*x is an expression. Again, little different from a language like Python.
  • So here's an interesting feature of Haskell: commands can return values. But a command that returns a value is different from an expression with a value.
  • We have to use <- instead of let ... = ... to get a returned value out of a command. It's a pretty simple rule, the only hassle is you have to remember what's a command and what's a function.
  • get2Lines = do line1 <- getLine line2 <- getLine return (line1,line2)
  • To introduce a list of commands, use do.To return a value from a command, use return.To assign a name to an expression inside a do block use let.To assign a name to the result of a command, use <-.
  • what's a command and what's an expression? If it has any chance of doing I/O it must be a command, otherwise it's probably an expression.
  • Everything in Haskell has a type, even commands. In general, if a command returns a value of type a then the command itself is of type IO a.
  • eturn is simply a function of type a -> IO a that converts a value of type a to a command of type IO a.
  • 5. The type of a sequence of commands is the type of the last line.
  • The type of an if statement is the type of its branches. So if you want an if statement inside a do block, it needs to be a command, and so its branches need to be commands also. So it's
  • If something is of type IO a then it's a command returning an value of type a. Otherwise it's an expression. That's the rule.
  • following the rules above it's completely impossible to put an executed command inside an expression.
  • As the only way to do I/O is with commands, that means you have no way to find out what Haskell is doing inside expressions.
  • If the type isn't IO a, then you can sleep at night in the confidence that there are no side effects.
  • One last thing. Much of what I've said above is false. But what I hope I have done is describe a subset of Haskell in which you can start some I/O programming without having a clue what a monad is.
  • The idea of capturing imperative computations in a type of (immutable) values is lovely. And so is the general pattern we call "monad".
  • main = do return 1 print "Hello"
Javier Neira

Understanding Haskell Monads - 0 views

  • The opposite of referentially transparent is referentially opaque. A referentially opaque function is a function that may mean different things and return different results each time, even if all arguments are the same.
  • a function that just prints a fixed text to the screen and always returns 0, is referentially opaque, because you cannot replace the function call with 0 without changing the meaning of the program.
  • n fact, a function, which doesn't take any arguments, isn't even a function in Haskell. It's simply a value. A number of simple solutions to this problem exist. One is to expect a state value as an argument and produce a new state value together with a pseudorandom number: random :: RandomState -> (Int, RandomState)
  • ...12 more annotations...
  • We have seen that we can solve this problem by expecting a state argument. But what's our state? The state of the terminal?
  • A general purpose language is almost useless, if you can't develop user interfaces or read files. We would like to read keyboard input or print things to the terminal.
  • We seem to have found a useful solution to our problem. Just pass the state value around. But there is a problem with this approach.
  • A very special feature of Haskell is the concept of generalization. That means, instead of implementing an idea directly, you rather try to find a more general idea, which implies your idea as a special case.
  • However, the traditional programmer never had to face generalization. At most they faced abstraction,
  • they are a very abstract structure, which allows implementing functionality at an incredibly general level.
  • Haskell [1] is a purely functional programming language. Functions written in it are referentially transparent. Intuitively that means that a function called with the same arguments always gives the same result.
  • askell takes another approach. Instead of passing the world state explicitly, it employs a structure from category theory called a monad.
  • They are an abstract structure, and at first it can be difficult to understand where they are useful. The two main interpretations of monads are as containers and as computations.
  • The ⊥ value is a theoretical construct. It's the result of a function, which never returns, so you can't observe that value directly. Examples are functions, which recurse forever or which throw an exception. In both cases, there is no ordinary returning of a value.
  • Now that Nothing is a valid result, our function handles all cases.
  • You have some computation with a certain type of result and a certain structure in its result (like allowing no result, or allowing arbitrarily many results), and you want to pass that computation's result to another computation.
1 - 3 of 3
Showing 20 items per page