CODEWITHSUNDEEP
swiftfunctional-programmingpromisecomputer-science
user965972
user965972

Reputation: 2587

CS: equality of a promise in functional programming

When are two promises considered equal in computer science? When the type is the same or the content?

As a more concrete example, I have a struct like this in swift:

 struct {
   case Value(@autoclosure () -> ValueType)
   case Error(@autoclosure () -> ErrorType)
   case None
 }

and an equality function:

func == <ValueType, ErrorType> (left: Promise<ValueType, ErrorType>, right: Promise<ValueType, ErrorType>) -> Bool
{
    switch (left, right)
    {
    case (.Value, .Value):  fallthrough
    case (.Error,.Error):   fallthrough
    case (.Nil, .Nil):
        return true
    default:
        return false
    }
}

or this:

func == <ValueType, ErrorType> (left: Promise<ValueType, ErrorType>, right: Promise<ValueType, ErrorType>) -> Bool
{
    switch (left, right)
    {
    case (.Value, .Value):  
        return left.value() == right.value()
    case (.Error,.Error):   
        return left.error() == right.error()
    case (.Nil, .Nil):
        return true
    default:
        return false
    }
}

Which one is the correct practice or does it depend on the application?

Upvotes: 1

Views: 154

Answers (2)

CodaFi
CodaFi

Reputation: 43330

The beautiful part about equality is that you get to define what it means yourself. If you'd like simple reference equality object Promises of object types, you can use the built in === operator. If you'd like reference equality over Promises themselves, the same applies. Or, if you're willing to restructure your Promise and give it a bit more meaning, you can define equality in much more interesting ways. For example, I've written a Future<T> that is always bound to a given pthread when it is being run or has finished executing, and to nothing if it hasn't been forced. This way, equality becomes checking the thread ID of each executing Future because there's a strong chance you won't get the same address twice from pthread_create(). You could bind each Promise with a unique identifier and break that relationship to a particular thread and define equality as the same UUID. Or equality could be some perversion of functional extensionality- where two Promises are equal if they have evaluated to the same form for the same data. The sky's the limit here.

Upvotes: 1

Benjamin Gruenbaum
Benjamin Gruenbaum

Reputation: 276296

There is no "standard" for promise equality in most languages. There is usually little sense to comparing them most of the time. There are a couple of things you run into though.

A promise is a temporal singular value, that is - it's a value that might or might not be available. Discussing equality between promises in Swift is rather arbitrary - there is nothing I can see to be gained from doing promise1 == promise2 and you have === for reference equality already.

I would simply not define the == operator on promises. If you want a notion of equality you should consider a temporal equality check - that is:

func willEqual(p1: Promise<ValueType, ErrorType>,
               p2: Promise<ValueType, ErrorType>) -> Promise<ValueType, ErrorType> {
     return p1.then { (val) in p2.then { (val2) in val == val2 }}
}

Which evaluates to true if and only if two promises will eventually be equal.

It's OK to not be able to define values as equal with == since like we said - they're not there yet.

Upvotes: 2

Related Questions