Skip to main content

Home/ Haskell/ Group items tagged level

Rss Feed Group items tagged

Javier Neira

Smart constructors - HaskellWiki - 0 views

  • The most interesting are probably the static checks that can be done with Type arithmetic, that enforce the number of bands at compile time, rather than runtime, by lifting the band count into the type level.
  • typecheck perform the check statically, using phantom types and Peano numbers.
  • So encode a type-level version of the bounds check. Only resistors with bands >= 4 and <= 8 are valid:
  • ...1 more annotation...
  • Further checks can be obtained by separating the metal and ceramic values on the type level, so no function that takes a metal resistor can be accidentally passed a ceramic one. A newtype is useful for this:
J.A. Alonso

Purely Functional Algorithm Specification ~ Jan van Eijck - 0 views

  •  
    This course offers a perspective on algorithm specification, in terms of purely functional programming. An algorithm is an effective method expressed as a list of instructions describing a computation for calculating a result. Algorithms have to be written in human readable form, either using pseudocode (natural language looking like executable code), a high level specification language like Dijkstra's Guarded Command Language, or an executable formal specification formalism such as Z. The course will develop a purely functional perspective on algorithm specification, and demonstrate how this can be used for specifying (executable) algorithms, and for automated testing of Hoare correctness statements about these algorithms. The small extension of Haskell that we will present and discuss can be viewed as a domain specific language for algorithm specification and testing. Inspiration for this was the talk by Leslie Lamport at CWI on the executable algorithm specification language PlusCal plus Edsger W. Dijkstra, "EWD472: Guarded commands, non-determinacy and formal derivation of programs." Instead of formal program derivation, we demonstrate test automation of Hoare style assertions.
Javier Neira

Understanding Monads Via Python List Comprehensions « All Unkept - 0 views

  • But here we have taken it to a higher level -- the Monad interface is like an abstraction of any kind of container.
  • This in turn leads to the concept that a monadic value represents a computation -- a method for computing a value, bound together with its input value.
  • Writing monads is hard, but it pays off as using them in Haskell is surprisingly easy, and allows you to do some very powerful things.
  • ...3 more annotations...
  • One of them you have seen explicitly -- it's the 'return' method, responsible for packing things up into the monad. The other is called 'bind' or '>>=', and it does the 'unpacking' involved with the <- arrow in the do notation.
  • the 'bind' method doesn't really unpack and return the data. Instead, it is defined in such a way that it handles all unpacking 'internally', and you have to provide functions that always have to return data inside the monad.
  • It looks very much like 'unpack this data from the monad so I can use it', so it helps conceptually. In fact, together with the rest of the body of the 'do' block it forms an anonymous lambda function,
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...
  • 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 have seen that we can solve this problem by expecting a state argument. But what's our state? The state of 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 - 5 of 5
Showing 20 items per page