Types as Interfaces
two-wrongs.com
Types as Interfaces
1–10 of 197 posts
Re: Types as Interfaces
#2Is this something professional programmers are having trouble with??
This is the kind of problem you face in your first year working, no? I am honetly curious what others think. Do you have trouble deciding when to use an interface (assuming your language has that), or a type wrapper (I don't think that's the brightest idea), or a function to extract the field to sort by (most languages do that)??
Re: Types as Interfaces
#3MLs require a lot of ceremony modelling simple record types.
What we want to express here is an object with a map of properties (name to type):
string Type map
Map
type Foo = { "_foo", int }
type Bar = { "_bar", string }
type FooBar = mergeMaps Foo Bar
Have any languages achieved this? I know TypeScript can do some of these things, but it's clunky.
Re: Types as Interfaces
#4I would love to just throw a field Optional[Datetime.UTC] on Msg type and call it a day :). Cool article got me thinking at 6:00 AM
Re: Types as Interfaces
#5Is this something professional programmers are having trouble with?? This is the kind of problem you face in your first year working, no? I am honetly curious what others think. Do you have trouble deciding when to use an interface (assuming your language has that), or a type wrapper (I don't think that's the brightest idea), or a function to extract the field to sort by (most languages do that)??
Most professional programmers don't worry much about elegance and just write code that gets the job done.
Re: Types as Interfaces
#6Is this something professional programmers are having trouble with?? This is the kind of problem you face in your first year working, no? I am honetly curious what others think. Do you have trouble deciding when to use an interface (assuming your language has that), or a type wrapper (I don't think that's the brightest idea), or a function to extract the field to sort by (most languages do that)??
Sometimes I do, not everyone is a big brain coder.
Re: Types as Interfaces
#7Is this something professional programmers are having trouble with?? This is the kind of problem you face in your first year working, no? I am honetly curious what others think. Do you have trouble deciding when to use an interface (assuming your language has that), or a type wrapper (I don't think that's the brightest idea), or a function to extract the field to sort by (most languages do that)??
> Is this something professional programmers are having trouble with??
Nobody said this.
There is value in thinking about things like this sometimes, because it has long-term consequences for the projects we work on. Even if you're a "professional" programmer (whatever that means), it's valuable to go back to beliefs and knowledge you've established long ago to evaluate whether to change them in the face of new experiences you've made since the last time you've thought about it.
If you think "professional" programmers don't get this sort of thing wrong in some form or another, I have a bridge to sell you.
Re: Types as Interfaces
#8MLs require a lot of ceremony modelling simple record types. What we want to express here is an object with a map of properties (name to type): string Type map For the OOP minded: Map And also compose those: type Foo = { "_foo", int } type Bar = { "_bar", string } type FooBar = mergeMaps Foo Bar But at compile-time, of course. Have any languages achieved this? I know TypeScript can do some of these things, but it's c…
This is often referred to as "row typing", and the only language I've ever used that implemented it first-class with polymorphism is Purescript[0]. It's possible to model such things in other languages with sufficiently powerful type systems, though they're normally not as nice to use.
As an aside, Purescript is one of the most fun languages I've ever used for frontend work, and I lament that Elm seems to have overtaken it in the FP community.
[0]: https://hgiasac.github.io/posts/2018-11-18-Record-Row-Type-a...
Re: Types as Interfaces
#9MLs require a lot of ceremony modelling simple record types. What we want to express here is an object with a map of properties (name to type): string Type map For the OOP minded: Map And also compose those: type Foo = { "_foo", int } type Bar = { "_bar", string } type FooBar = mergeMaps Foo Bar But at compile-time, of course. Have any languages achieved this? I know TypeScript can do some of these things, but it's c…
Scala 3 can do it with some macro tricks. But the performance is not as good as with nominally typed structures.
Re: Types as Interfaces
#10MLs require a lot of ceremony modelling simple record types. What we want to express here is an object with a map of properties (name to type): string Type map For the OOP minded: Map And also compose those: type Foo = { "_foo", int } type Bar = { "_bar", string } type FooBar = mergeMaps Foo Bar But at compile-time, of course. Have any languages achieved this? I know TypeScript can do some of these things, but it's c…
I think what you describe is called "extensible records". Elm had them in a prior version. You can implement them in a language with an expressive enough type system (e.g. Haskell or Scala) without special support, but the syntax can be a bit unwieldy.
Here's three recent papers on extensible records:
* https://arxiv.org/pdf/2108.06296 * https://arxiv.org/pdf/2404.00338 * https://dl.acm.org/doi/pdf/10.1145/3571224
I'm not claiming these are definitive in any sense, but they are useful guides into the literature if any reader wants to learn more. (If you are not used to reading programming language papers, the introduction, related work, and conclusions are usually the most useful. All the greek in the middle can usually be skipped unless you are trying to implement it.)