7 ms·
Fine. Now propose a concrete type-checking algorithm. And make it scalable.
by catnaroek 9y ago
Fine. Now propose a concrete type-checking algorithm. And make it scalable.
- wtetzner 9y agoI think row types are probably what OP is looking for. And they can be fully inferred.
- catnaroek 9y agoI don't think row polymorphism is what the OP asked for. They might be what the OP wants, but that's a-whole-nother matter. If I understood correctly, the OP asked for a “duck type of all values on which a function `f` can be applied”. Alas, OCaml-like object types are glorified function types, not duck types: (0) The type of an object is the type of its methods. (1) The type of an object is not the type of its internal state. Say you have a particular data type like `float list`, and you want to “bless it with a method `f`”, so that you can pass a `float list` to any context that expects an object with a method `f`. This is everyday stuff in duck-typed languages. Turns out, you can't. The best thing you can do is explicitly construct an object with a method `f`, and whose state happens to be a `float list`. Alas, because the state isn't a part of the object's type, there is no way a user of the object can recover the original `float list`. In fact, no user of the object has any way to tell whether the object's internal state is a `float list` or something else altogether.
- wtetzner 9y ago> I don't think row polymorphism is what the OP asked for. They might be what the OP wants, but that's a-whole-nother matter. I think that's the other way around. It appears to be what they asked for, even if it may not be what they want. They pretty clearly said they wanted to be able to write a type that says "Object that has method f :: a -> Int". What you're talking about doesn't seem to be duck typing (though it might work nicely along side duck typing), it's being able to add methods to objects at run time (unless I'm misunderstanding).