5 ms·

Row polymorphism is excellent. I was intro'd to it in Purescript, but I would like to say that Typescript gives you some things that rhyme with it through its c

by rtpg 2y ago

Row polymorphism is excellent. I was intro'd to it in Purescript, but I would like to say that Typescript gives you some things that rhyme with it through its combinations of records at the type level. Highly recommend people mess around with Purescript, you can feel how much pressure is relieved thanks to the row polymorphism tooling almost instantly. Truly, all we wanted as an industry is an easy way to bundle together various tags into our types, and row polymorphism gets you there. I think row polymorphism is a fairly straightforward thing compared to dependent types in general, but can let you crush a whole class of errors and pay almost nothing in terms of expression costs.

enugu 2y ago
Somtime ago, there was a debate on the ability of a static type system to model an 'open-world situation' where fields are added to records as model changes. (based on a post[1] which responded to a Rich Hickey talk). The crucial point was that structural typing on which row-polymorphism is based can model such open-world situations. Also, having such a system can free you from having overly nested types. It would be great if Purescript or row-polymorphism became more popular. [1] https://news.ycombinator.com/item?id=22090700 https://news.ycombinator.com/item?id=22090700
- arianvanp 2y ago
  This is also why I like interfaces in Golang (as a Haskell developer). You simply define a slice of the world you want to see and anything that fits the box can be passed. It's just unfortunate golang interfaces dont support fields. Only methods. Typescript fares better with its interface type
  - diggan 2y ago
    > It's just unfortunate golang interfaces dont support fields. Only methods. Why is that unfortunate? Usually when defining interfaces you care about the API surface without wanting to care about the internals of what will eventually implement that API. If you suddenly also spec fields with the interface, wouldn't be too easy to couple the internals to the API? I can't say I've programmed in Go too much, so maybe I'm missing something very obvious.
    - n0w 2y ago
      The API surface of some struct is determined by visibility, not by whether a member of the struct is a method or a field. I can't remember the specifics for why fields cannot be used within a Go interface but I do remember missing it a few times while writing Go code.
      - fwip 2y ago
        I think the reasoning is that interfaces are implemented by a dynamic lookup. Part of Go's philosophy is that things that could be expensive (function calls) should be visually distinct from cheap things. Struct field access is cheap, hopping through a dynamic dispatch table is less cheap.
        rtpg 2y ago
        Took me a second to grok why the field access would require dynamic dispatch and it's because you have to deal with differing layout between structs.
tmountain 2y ago
PureScript is such a cool language. I wish it would get more traction, but it feels like it's competing in the same space as TypeScript, and TypeScript seems to solve the category of problems it addresses well enough for most people.
runeks 2y ago
> Highly recommend people mess around with Purescript, you can feel how much pressure is relieved thanks to the row polymorphism tooling almost instantly. > I think row polymorphism is a fairly straightforward thing compared to dependent types in general, but can let you crush a whole class of errors [...] Would you care to provide a few examples? I don't have experience with row polymorphism so I'm genuinely curious.
- tmountain 2y ago
  greet :: forall r. { name :: String | r } -> String greet person = "Hello, " <> person.name <> "!" greetWithAge :: forall r. { name :: String, age :: Int | r } -> String greetWithAge person = "Hello, " <> person.name <> "! You are " <> show person.age <> " years old." main :: Effect Unit main = do let person = { name: "Alice", age: 30, occupation: "Engineer" } -- greet can accept the person record even though it has more fields log (greet person) -- Output: "Hello, Alice!" -- greetWithAge can also accept the person record log (greetWithAge person)
  - blue_pants 2y ago
    How does it differ from structural typing in TypeScript though?
    - tmountain 2y ago
      Structural typing relies on interface compatibility. Row polymorphism is a type-level feature in PureScript where record types are constructed with an explicit "row" of fields. In Practice, row polymorphism is more granular, allowing you to explicitly allow certain fields while tracking all other fields via a ("rest") type variable. Example: PureScript allows you to remove specific fields from a record type. This feature, is called record subtraction, and it allows more flexibility when transforming or narrowing down records. You can also apply exact field constraints; meaning, you can constrain records to have exactly the fields you specify. Lastly, PureScript allows you to abstract over rows using higher-kinded types. You can create polymorphic functions that accept any record with a flexible set of fields and can transform or manipulate those fields in various ways. This level of abstraction is not possible in TypeScript. These are just a few examples. In the most general sense, you can think of row polymorphism as a really robust tool that gives you a ton of flexibility regarding strictness and validation.

by rtpg 2y ago

enugu 2y ago

Somtime ago, there was a debate on the ability of a static type system to model an 'open-world situation' where fields are added to records as model changes. (based on a post[1] which responded to a Rich Hickey talk). The crucial point was that structural typing on which row-polymorphism is based can model such open-world situations. Also, having such a system can free you from having overly nested types. It would be great if Purescript or row-polymorphism became more popular. [1] https://news.ycombinator.com/item?id=22090700 https://news.ycombinator.com/item?id=22090700

arianvanp 2y ago
This is also why I like interfaces in Golang (as a Haskell developer). You simply define a slice of the world you want to see and anything that fits the box can be passed. It's just unfortunate golang interfaces dont support fields. Only methods. Typescript fares better with its interface type
- diggan 2y ago
  > It's just unfortunate golang interfaces dont support fields. Only methods. Why is that unfortunate? Usually when defining interfaces you care about the API surface without wanting to care about the internals of what will eventually implement that API. If you suddenly also spec fields with the interface, wouldn't be too easy to couple the internals to the API? I can't say I've programmed in Go too much, so maybe I'm missing something very obvious.
  - n0w 2y ago
    The API surface of some struct is determined by visibility, not by whether a member of the struct is a method or a field. I can't remember the specifics for why fields cannot be used within a Go interface but I do remember missing it a few times while writing Go code.
    - fwip 2y ago
      I think the reasoning is that interfaces are implemented by a dynamic lookup. Part of Go's philosophy is that things that could be expensive (function calls) should be visually distinct from cheap things. Struct field access is cheap, hopping through a dynamic dispatch table is less cheap.
      - rtpg 2y ago
        Took me a second to grok why the field access would require dynamic dispatch and it's because you have to deal with differing layout between structs.

tmountain 2y ago

PureScript is such a cool language. I wish it would get more traction, but it feels like it's competing in the same space as TypeScript, and TypeScript seems to solve the category of problems it addresses well enough for most people.

runeks 2y ago

> Highly recommend people mess around with Purescript, you can feel how much pressure is relieved thanks to the row polymorphism tooling almost instantly. > I think row polymorphism is a fairly straightforward thing compared to dependent types in general, but can let you crush a whole class of errors [...] Would you care to provide a few examples? I don't have experience with row polymorphism so I'm genuinely curious.

tmountain 2y ago
greet :: forall r. { name :: String | r } -> String greet person = "Hello, " <> person.name <> "!" greetWithAge :: forall r. { name :: String, age :: Int | r } -> String greetWithAge person = "Hello, " <> person.name <> "! You are " <> show person.age <> " years old." main :: Effect Unit main = do let person = { name: "Alice", age: 30, occupation: "Engineer" } -- greet can accept the person record even though it has more fields log (greet person) -- Output: "Hello, Alice!" -- greetWithAge can also accept the person record log (greetWithAge person)
- blue_pants 2y ago
  How does it differ from structural typing in TypeScript though?
  - tmountain 2y ago
    Structural typing relies on interface compatibility. Row polymorphism is a type-level feature in PureScript where record types are constructed with an explicit "row" of fields. In Practice, row polymorphism is more granular, allowing you to explicitly allow certain fields while tracking all other fields via a ("rest") type variable. Example: PureScript allows you to remove specific fields from a record type. This feature, is called record subtraction, and it allows more flexibility when transforming or narrowing down records. You can also apply exact field constraints; meaning, you can constrain records to have exactly the fields you specify. Lastly, PureScript allows you to abstract over rows using higher-kinded types. You can create polymorphic functions that accept any record with a flexible set of fields and can transform or manipulate those fields in various ways. This level of abstraction is not possible in TypeScript. These are just a few examples. In the most general sense, you can think of row polymorphism as a really robust tool that gives you a ton of flexibility regarding strictness and validation.