3 ms·

Excellent overview, OCaml is quickly becoming a powerful and flexible tool in almost all aspects comparable to other languages and has its own unique strength l

by a0 12y ago

Excellent overview, OCaml is quickly becoming a powerful and flexible tool in almost all aspects comparable to other languages and has its own unique strength like module functors and polymorphic variants. > The only other feature I'd like to see is a unification of the object system and record system: (...) Could you elaborate a little bit on this or maybe point an article about it? Thanks.

jordwalke 12y ago
I'm not the best person to elaborate, but I'll explain from my limited knowledge. OCaml actually has a very complete object system (with ugly syntax, but don't judge). It's similar to OO you're used to in Java etc, but the types are often inferred instead of requiring that you state up front that classes/objects are subtypes of other classes. It allows you to use objects just as you would records, except: 1. You don't have to predefine the object types anywhere - with records you do. 2. With OCaml "objects", you get inferred "row polymorphism", which means that you can make a function (without any type annotations) that accepts a point, and accesses point.x, and point.y. This function will also, gladly accept a 3D point that has an extra field point.z, that the function never accesses. In OCaml, you never even needed to predefine a type for 2DPoint or 3DPoint. This is similar to, but different than the OO "subtyping" that you're used to in OO languages. 3. Records don't provide this "row polymorphism" that OCaml objects provide. 4. Records do allow pattern matching. 5. I would like to see the best of both. Pattern matching and row polymorphism into one new record abstraction. I'm sure there are tradeoffs (likely something to do with predictable memory layout accommodating efficient instructions). Row polymorphism may make type inference times longer, or error messages less readable. I'm definitely not the right person to give an overview of this - so please do your own investigation on the tradeoffs. I'd love to hear an expert chime in. But all in all, I'm happy with records and the performance I see. Named arguments (with optional defaults) (which OCaml has) can fulfill the role of a unified record/object system, in some cases.

by a0 12y ago

jordwalke 12y ago

I'm not the best person to elaborate, but I'll explain from my limited knowledge. OCaml actually has a very complete object system (with ugly syntax, but don't judge). It's similar to OO you're used to in Java etc, but the types are often inferred instead of requiring that you state up front that classes/objects are subtypes of other classes. It allows you to use objects just as you would records, except: 1. You don't have to predefine the object types anywhere - with records you do. 2. With OCaml "objects", you get inferred "row polymorphism", which means that you can make a function (without any type annotations) that accepts a point, and accesses point.x, and point.y. This function will also, gladly accept a 3D point that has an extra field point.z, that the function never accesses. In OCaml, you never even needed to predefine a type for 2DPoint or 3DPoint. This is similar to, but different than the OO "subtyping" that you're used to in OO languages. 3. Records don't provide this "row polymorphism" that OCaml objects provide. 4. Records do allow pattern matching. 5. I would like to see the best of both. Pattern matching and row polymorphism into one new record abstraction. I'm sure there are tradeoffs (likely something to do with predictable memory layout accommodating efficient instructions). Row polymorphism may make type inference times longer, or error messages less readable. I'm definitely not the right person to give an overview of this - so please do your own investigation on the tradeoffs. I'd love to hear an expert chime in. But all in all, I'm happy with records and the performance I see. Named arguments (with optional defaults) (which OCaml has) can fulfill the role of a unified record/object system, in some cases.