Hacker News Reader

Comment by emillon | Hacker News Reader

I like to see this as a sort of duality: closures are objects that have a single method (call) and objects are made of functions that can only capture one variable (this).

View on HN

You can have as many methods as you like. Here's an example comparing one with the other in Golang: http://play.golang.org/p/TXZlZL7Tl8

That's not a closure. That's returning a struct. That struct is an object that has several instance members that are functions, which you've created as closures, but note you're still returning a struct. To return a closure, you need to return a function type, which then has exactly one way to call it, which is the claim here about functions.

Of course you can dispatch anything you like within that call, turning a closure back into "methods", although in most languages that's a fairly painful way to operate even though if it is possible. Personally over the years I've come more around to tel's point of view, which is that as related as objects and closures may be, they aren't quite just two sides of the same coin, as further evidenced by the fact that pretty much all modern OO languages also include closures. If they really were the same thing in two guises somebody would probably have fully unified them by now, but they aren't the same thing. As much fun as the koan is, I think it's false wisdom.

> which you've created as closures, but note you're still returning a struct

a struct of three closures :)

EDIT:

I'm not sure I understand your point. Here's how to return three closures without the struct.

http://play.golang.org/p/9UtJ7ZBMzb

Yes, I said that. Please try less hard for the "gotchas". There's no ambiguity here, the Go type system does not permit it; something is either a struct or a closure (or exactly one of the other valid types; even "interfaces" are actually a specific type in Go), and the linked code returns a struct. (Python, for instance, can create something that acts as both object and closure at the same time with an object that implements the __call__ magic method.)

The spot I start to feel fuzzy, though, is if you start talking about higher-level abstractions. E.g, are interfaces equivalent to type classes?

Depends if you have multiple inheritance.

Interfaces—at least in C#/Java—are equivalent to product types; they let you express the notion of conjunction within the type system.

Similarly, “implementation inheritance” (where every class is either sealed/final or abstract) is how we express sum types.

We can simulate type classes in C# by using implicit casts to abstract classes (interestingly, it’s not so straightforward to simulate the awesomeness of type classes in F#).

The key to all of this is to realize that “types” and “classes” are not equivalent, even though C# and Java conflate them.

You have to specify the language; there's no (useful) definition of type classes and interfaces outside of the context of a specific language that is specific enough to make reliable comparisons.

If you mean "Are Haskell type classes equivalent to Go interfaces?", the answer is no, Haskell type classes are substantially more powerful, even before you start turning on extensions. For instance, "Go" can not express the Monad typeclass at all.

I was more thinking Haskell type classes vs. C# or Java interfaces. They're a bit more powerful than Go interfaces because they can be used in combination with generics.

The Monad type class is a pretty good test. Last I knew it wasn't properly expressible in C# or Java either in the fully general sense, though you can get closer than Go, certainly. Whether it gets close enough that you can call it "done" is a bit of a judgment call; in the end, the semantics are never quite identical even in the best of cases.

As others have exemplified: it gets really hard to talk about this stuff outside of formal models. Especially if your goal is to talk about equivalency.

At this point I start trying to turn toward System F, but that's my hammer for this particular nail and I don't know an equivalent one in the object side of things. I'm certain you can express higher-level things in System F which are equivalent to interfaces. I know there's a translation of typeclasses to System F—it's called Haskell, har har—although you have to recognize that the "search" component of typeclasses will be lost.

Yes, it's not very formal and as others said it would need some definitions to make a useful result.

But actually I don't think that this duality is related to types: in a static language, the types of captured variables does not appear in a value's type. And for the object side, the type of instance variables is hidden behind the public interface too.

So it's really more about techniques for creating abstractions than how the values are composed together.

Reply on news.ycombinator.com