3 ms·

I've been thinking about structural vs nominal. As you say, both have use cases. How would you combine both in one language so it's not confusing?

by slver 5y ago

swsieber 5y ago
Restrict structural types to tuples only.
- slver 5y ago
  That honestly won’t be very useful.
amitport 5y ago
TypeScript!
valenterry 5y ago
I'm not sure, but I think I would make a language based on structural typing only, including to allow a structural type to contain names. (Scala actually already has literal types that come close) Think about the following type-level (not runtime) representation for a structural type (tuple): (String -> Integer) And the following for a structural type with where each "member" has a name: (("name" -> String) -> ("age" -> Integer)) And the following for a named structural type where each "member" has a name: ("User" -> (("name" -> String) -> ("age" -> Integer))) The last structural type here would be equivalent to a class/record in Java. I would then add syntax that makes working with these special kinds of structural types more easy. So record User (String name, Integer age) would translate to the structure above. But one could also do something like that _if they wanted to_: ("User" -> (("field1" -> ("name" -> String)) -> ("field2" -> ("age" -> Integer)))) The closed equivalent would be a Java record where each member is annotated. This could be used to serialize/deserialize it into json. I think that's what I would try :) but I'm not a PL designer.
- didibus 5y ago
  OCaml does this I believe.
- kaba0 5y ago
  I think nominal types are a must, otherwise you lose most of the benefits of static typing. Is an Email type the same as a String even though they are the same under the hood? I precisely should not accept it without explicitly casting it, otherwise I would have duck typing. But I agree that explicit structural types can be useful at places.
  - valenterry 5y ago
    I think you misunderstood my idea. For example, check the User that I defined. Even if you would have another type with the same structure, the name would be different, so it would not be interchangeable without a "cast", even though both are ultimately structural types. It's just that the name is now part of the structural definition.

I've been thinking about structural vs nominal. As you say, both have use cases. How would you combine both in one language so it's not confusing?

by slver 5y ago

I've been thinking about structural vs nominal. As you say, both have use cases. How would you combine both in one language so it's not confusing?

swsieber 5y ago

Restrict structural types to tuples only.

slver 5y ago
That honestly won’t be very useful.

amitport 5y ago

TypeScript!

valenterry 5y ago

I'm not sure, but I think I would make a language based on structural typing only, including to allow a structural type to contain names. (Scala actually already has literal types that come close) Think about the following type-level (not runtime) representation for a structural type (tuple): (String -> Integer) And the following for a structural type with where each "member" has a name: (("name" -> String) -> ("age" -> Integer)) And the following for a named structural type where each "member" has a name: ("User" -> (("name" -> String) -> ("age" -> Integer))) The last structural type here would be equivalent to a class/record in Java. I would then add syntax that makes working with these special kinds of structural types more easy. So record User (String name, Integer age) would translate to the structure above. But one could also do something like that _if they wanted to_: ("User" -> (("field1" -> ("name" -> String)) -> ("field2" -> ("age" -> Integer)))) The closed equivalent would be a Java record where each member is annotated. This could be used to serialize/deserialize it into json. I think that's what I would try :) but I'm not a PL designer.

didibus 5y ago
OCaml does this I believe.
kaba0 5y ago
I think nominal types are a must, otherwise you lose most of the benefits of static typing. Is an Email type the same as a String even though they are the same under the hood? I precisely should not accept it without explicitly casting it, otherwise I would have duck typing. But I agree that explicit structural types can be useful at places.
- valenterry 5y ago
  I think you misunderstood my idea. For example, check the User that I defined. Even if you would have another type with the same structure, the name would be different, so it would not be interchangeable without a "cast", even though both are ultimately structural types. It's just that the name is now part of the structural definition.