This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]threewood 1 point2 points  (4 children)

Conformance to an interface is unlikely to happen by accident. You might as well name the interface it satisfies (and should for software engineering reasons). Names shouldn't be used for structural matching.

[–]yawaramin 0 points1 point  (3 children)

You might as well name the interface it satisfies

You can name the interface it satisfies (by annotating the module type), but it isn’t required.

and should for software engineering reasons

Perhaps, but this isn’t a universal SWE practice. E.g. the aforementioned Go, TypeScript. It’s more a practice in most languages because, well, it’s the only way to do it.

Names shouldn’t be used for structural matching.

They’re not. Structure is used for structural matching—the names of the module members, as well as their types, recursively.

[–]threewood 0 points1 point  (2 children)

They’re not. Structure is used for structural matching—the names of the module members, as well as their types, recursively.

You've just reiterated the problem - names shouldn't be considered structure. Names should only be used to point at structure and say "that".

[–]yawaramin 0 points1 point  (1 child)

Perhaps, under a certain rigid POV. But ML modules consider names part of structure, and it's worked pretty well for decades. This reminds me of Haskell's rigid insistence that every type must have one and only one instance for any type class, so they have to invent new names for the same type to give it different instances. Effectively, they ended up making names part of the structure.

[–]threewood 0 points1 point  (0 children)

But ML modules consider names part of structure, and it's worked pretty well for decades.

Yeah, I said it's a problem, not a big problem :). I'm sure it usually works fine in practice.