4 ms·
> Actually, records are even better* than tuples. EP 395 says: > > Records can be thought of as nominal tuples. They are certainly not better, that's just a sa
by valenterry 6y ago
> Actually, records are even better* than tuples. EP 395 says:
> > Records can be thought of as nominal tuples.
They are certainly not better, that's just a sad click-bait (the author even admits that).
Sometimes nominal typing is better and sometimes structural typing is better. Forcing people to always use nominal types just ends in a lot of generic or long/meaningless names - one can already see this in Java.
- The_rationalist 6y agoNominal !≠ named You can have named tuple members while maintaining structural typing, it's not mutually exclusive.
- valenterry 6y agoDid I say something that contradicts that?
- slver 6y agoI'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 6y agoRestrict structural types to tuples only.
- slver 6y agoThat honestly won’t be very useful.
- amitport 6y agoTypeScript!
- valenterry 6y agoI'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 6y agoOCaml does this I believe.
- kaba0 6y agoI 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 6y agoI 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.
- kelnos 6y agoMy general rule (in Scala) is that if I need a tuple larger than two or three elements, I'm better of writing a case class. Tuples get unreadable real fast. I think tuples are an essential language feature (and it's ridiculous that Java doesn't have them yet), but I think they're often way overused.
- valenterry 6y agoMy heuristics is much more based on how often the same structure is used and in which places. Sometimes type aliases are a more light way compromise too.