News aggregator

Philip Wadler: Propositions as Types, with Howard on Curry-Howard

Planet Haskell - Sat, 11/29/2014 - 10:12am
Propositions as Types has been updated, again. Thanks again to all the readers and reviewers who helped me improve the paper. This version includes an appendix, Howard on Curry-Howard, including additional correspondence with Howard not previously published.

Propositions as Types
Philip Wadler
Draft, 29 November 2014The principle of Propositions as Types links logic to computation. At first sight it appears to be a simple coincidence---almost a pun---but it turns out to be remarkably robust, inspiring the design of theorem provers and programming languages, and continuing to influence the forefronts of computing. Propositions as Types has many names and many origins, and is a notion with depth, breadth, and mystery.Comments still solicited!

Categories: Offsite Blogs

Bill Atkins: Unit Testing in Swift

Planet Haskell - Sat, 11/29/2014 - 9:27am
Since Swift was released at the beginning of the month, I've been doing using it for most of my iOS development. It's been a pleasant experience: I've been able to discard huge amounts of boilerplate and take advantage of a few functional programming techniques that were previously unavailable on the iPhone and iPad.

One area where Swift has made huge improvements over Objective-C is unit tests. Objective-C's verbosity made it difficult to create small, focused classes to perform specific tasks. Plus, the language's insistence on keeping only one class to a file and the cumbersome pairing of every implementation file with a header imposed a hefty penalty on programmers who tried to divide their work up into discrete, testable components.

Unit testing in Swift is done with the same XCTest framework introduced back in Xcode 5 for Objective-C. But Swift's concision and its inclusion of modern language features like closures makes XCTest much more pleasant than it was to use under Objective-C. We'll walk through a very simple example of Swift unit testing below.

To get started, create an empty iOS Application project in Xcode called Counter. Xcode will generate a CounterTests folder for you and an associated test target.

First, let's create a simple class to be tested. Create the file "Counter.swift" and add the following code to it:

import Foundation
public class Counter {  public var count: Int    public init(count: Int) {    self.count = count  }    public convenience init() {    self.init(count: 0)  }    public func increment() {    self.count++  }
This is a very simple class, but it will be enough to illustrate how to use XCTest to test your own Swift code.

UPDATE: Note that as of Xcode 6.1, any symbols that you want to be visible in your test case should be declared public so they can be seen from the test target, which is distinct from your main application target. In the above example, the class above and any of its members that need to be accessed in the test case have been declared public. Thanks to Kaan Ersan for pointing this out in the comments.

Create a file called "CounterTest.swift" in the CounterTests folder Xcode generated for you (this simple test will be your "Hello, world" for Swift testing):

import XCTestimport Counter
class CounterTest: XCTestCase {  func testSimpleAddition() {    let counter = Counter()    XCTAssertEqual(0, counter.count)  }
NOTE: In the current version of Swift (Beta 2), you have to import your main target into the test target to get your tests to compile and run. This is why we import Counter at the top.

NOTE: I've seen a few Swift tutorials recommend that you use the built-in Swift function assert in your test cases - do not do this! assert will terminate your entire program if it fails. Using the XCTAssert functions provides a number of important benefits:

  • If one test case fails, your other cases can continue running; assert stops the entire program.
  • Because the XCTAssert functions are more explicit about what you're expecting, they can print helpful failure messages (e.g. "2 was not equal to 3") whereas assert can only report that its condition was false. There's a broad variety of assert functions, including XCTAssertLessThan, XCTAssertNil, etc.
  • The Swift language specification explicitly forbids string interpolation in the message passed to assert; the XCTAssert functions don't face this limitation.
To try your test code out, click "Test" on the "Product" menu. Your single test should pass.
We'll add two more test cases to create and exercise several instances of Counter and to ensure that the counter wraps around when it overflows:
import XCTestimport Test
class CounterTest: XCTestCase {  func testInvariants() {    let counter = Counter()    XCTAssertEqual(0, counter.count, "Counter not initialized to 0")        counter.increment()    XCTAssertEqual(1, counter.count, "Increment is broken")
    XCTAssertEqual(1, counter.count, "Count has unwanted side effects!")  }    func testMultipleIncrements() {    let counts = [1, 2, 3, 4, 5, 6]        for count in counts {      let counter = Counter()            for i in 0..count {        counter.increment()      }            XCTAssertEqual(counter.count, count, "Incremented value does not match expected")    }  }    func testWraparound() {    let counter = Counter(count: Int.max)    counter.increment()        XCTAssertEqual(counter.count, Int.min)  }}
These tests should pass as well.

You can find out more about XCTest in the Apple guide "Testing with Xcode." I hope this was helpful - please feel free to comment if anything is unclear.
Categories: Offsite Blogs

Ajhc is no more

Haskell on Reddit - Sat, 11/29/2014 - 5:12am
Categories: Incoming News

Record equivalent to subclassed member variables?

Haskell on Reddit - Sat, 11/29/2014 - 3:05am

Let's say we're developing some sort of GUI and we want a TextField widget to display text in a window:

data TextField = TextField { text :: String, update :: TextField -> IO TextField, display :: TextField -> IO () }

We can create different kinds of TextFields, e.g.:

{- Assume these are defined: getClockTimeStr :: IO String drawGUIString :: String -> IO () -} clockTextField = TextField { text = "", update = \tf -> getClockTimeStr >>= \time -> return $ tf {text = time}, display = \tf -> drawGUIString $ text tf }

This seems ok so far, but now what if want a more sophisticated TextField that requires keeping track of additional internal state?

For example, maybe we want a complicated TextField that randomly displays either text or an image, and changes the image on mouse click. We now need to store an image in the TextField, but we don't want to just make it an additional field in TextField because it's very specific to this particular TextField behavior. We could parameterize:

data TextField a = TextField { {- ... -} state :: a }

or define a new type ImageTextField except then we lose the ability to have a list of any TextFields with [TextField], which is something we really really want for our GUI windows.

data GUIWindow { {- ... -} textFields :: [TextField] }

In a language with inheritance you can define a TextField abstract class and subclass a ComplicatedTextField with a new image member variable. This isn't applicable here, so I'm trying to figure out the correct alternative. I see two approaches to dealing with this, neither of which seem great:


Approach 1: Closures

{- Assume these are defined: data Image drawGUIImage :: Image -> IO () isMouseClicked :: IO Bool loadRandomImage :: IO Image randomlyTrue :: IO Bool someImage :: Image -} complicatedUpdate :: Image -> TextField -> IO TextField complicatedUpdate image tf = do clicked <- isMouseClicked image' <- if clicked then loadRandomImage else return image return $ tf { update = complicatedUpdate image', display = complicatedDisplay image' } complicatedDisplay :: Image -> TextField -> IO TextField complicatedDisplay image tf = do showImage <- randomlyTrue if showImage then drawGUIImage image else drawGUIString (text tf) complicatedTextField = TextField { text = "foobar", update = complicatedUpdate someImage, display = complicatedDisplay someImage, }

This would work but seems kind of tedious (potentially need to update a lot of functions) and error prone (what if we forget to update a function's closure?)

Approach 2: Data.Dynamic

import Data.Dynamic data TextField = TextField { {- ... -} state :: Dynamic }

and then define data types for each TextField's internal state, and make them instances of Typeable, etc. Now TextField display/update can access the state field and convert from/to Dynamic/the actual data type. This would also work but seems tedious as well (having to convert between the types, and the notion of having a default value for the conversions is odd here).


Is there a better approach to solve this issue? What's the equivalent to subclassed member variables in other languages for haskell records?

submitted by nonexistent_
[link] [20 comments]
Categories: Incoming News

What type does the empty list have

Haskell on Reddit - Sat, 11/29/2014 - 12:41am

In ghci, when I enter :t [], I get [] :: [t]. What does [t] mean?

submitted by lolb
[link] [10 comments]
Categories: Incoming News

How to mentor someone.

Haskell on Reddit - Fri, 11/28/2014 - 8:53pm
Categories: Incoming News

Motivation for Monads : haskell - Fri, 11/28/2014 - 1:37pm
Categories: Offsite Blogs

Motivation for Monads : haskell - Fri, 11/28/2014 - 1:37pm
Categories: Offsite Blogs

Motivation for Monads

Haskell on Reddit - Fri, 11/28/2014 - 12:06pm
Categories: Incoming News