loading...

Is there/could there be a language with automatic interfaces?

yujiri8 profile image Ryan Westlund ・1 min read

Go demonstrates basically the concept of interfaces I have in mind: anything that satisfies the interface can be used as it, without having to be specifically declared as implementing it. And there are languages with good type interference, like Haskell. So that makes me wonder: what about a language where the interfaces don't even have to be declared?

Even in Haskell, typeclasses are defined somewhere. And in fact, since Haskell doesn't have method namespacing, and doesn't normally allow overloading a top-level name with different type signatures, you have to use a typeclass to get polymorphism - it's the only way a function can be allowed to take two unrelated types.

Here's a simple class in Haskell:

class YesNo a where
 yesno :: a -> Bool

instance YesNo Int where
 yesno 0 = False
 yesno _ = True

instance YesNo [a] where
 yesno [] = False
 yesno _  = True

main :: IO ()
main = return ()

What if I didn't need to define the class, only the two yesno verisons, like so?

yesno :: Int -> Bool
yesno x = x /= 0

yesno :: [a] -> Bool
yesno x = not $ null x

That isn't allowed in current Haskell, but what if it was? I can't think of any reason why there couldn't be a language that allowed this. Essentially, one where interfaces are not only implemented automatically, but defined automatically.

Posted on by:

yujiri8 profile

Ryan Westlund

@yujiri8

I'm a programmer, writer, and philosopher. My Github account is yujiri8; all my content besides code is at yujiri.xyz.

Discussion

markdown guide
 

Interfaces exist to enable functions to receive the right form of data. What's the actual thing that contains that data? The function doesn't really care, as long as it has that data. And that's the real purpose.

The concept of classes implementing interfaces is fundamentally wrong IMO. Interfaces should only exist to enable comunication between two functions. That's where Go does this right.

Still, I don't see the point of your suggestion of automatically defined interfaces. Sure, you could actually make a language that would do that. But, the purpose of interfaces is to constrain the data that's allowed into a function. Your proposal would be permissive, not constraining. In your example, yesno should return Bool. What if I add a new yesno like this: yesno :: [a] -> Int? That should also work with this imaginary language and it defeats the purpose of an interface.

 

What if I add a new yesno like this: yesno :: [a] -> Int? That should also work with this imaginary language and it defeats the purpose of an interface.

It could check the type signatures too, so a function like invertYesNo val = not $ yesno val could reject arguments whose yesno instance doesn't return Bool. Since invertYesNo calls yesno and plugs the result into a Bool -> Bool, the implied interface of its argument would require yesno :: a -> Bool, not just yesno :: a -> b.

 

Hmm, okay, your argument stands. It is very opinionated though, there's no real reason why an interface couldn't return two types of data.

 

The class object is an implied interface in Typescript and JavaScript. The JavaScript Object is not an implied interface because any object can contain any property. I tend to favor classes over interface and do appreciate the traditional JavaScript object too.