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

It's just unfortunate golang interfaces dont support fields. Only methods. Typescript fares better with its interface type

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.

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.

Struct field access is cheap, hopping through a dynamic dispatch table is less cheap.

> 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.

  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)

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.

TypeScript does allow you to remove specific fields, if I understand you right [0]:

    function removeField<T, K extends keyof T>(obj: T, field: K): Omit<T, K> {
        const { [field]: _, ...rest } = obj;
        return rest;
    }

    type Person = { name: string; age: number };
    declare const p: Person;
    const result = removeField(p, 'age'); // result is of type: Omit<Person, "age">

Again, if I understand you correctly, then TypeScript is able to do fancy manipulations of arbitrary records [1]:

    type StringToNumber<T> = {
        [K in keyof T]: T[K] extends string ? number : T[K]
    }

    function stringToLength<T extends Record<string, unknown>>(obj: T): StringToNumber<T> {
        const result: Record<string, unknown> = {};
        for (const key in obj) {
            result[key] = typeof obj[key] === 'string' ? obj[key].length : obj[key];
        }
        return result as StringToNumber<T>;
    }

    const data = {
        name: "Alice",
        age: 30,
        city: "New York"
    };

    const lengths = stringToLength(data);

    lengths.name // number
    lengths.age // number
    lengths.city // number

[1] https://www.typescriptlang.org/play/?#code/C4TwDgpgBAysBOBLA...

edit: provided links to TS playground

const r1: { a: number; b: number } = { a: 10, b: 20 };

const r2: { a: number } = r1;

const r3: { a: number; b: string } = { b: "hello", ...r2 };

console.log(r3.b) // typescript thinks it's a string, but actually it's a number

The problem in question can be "fixed" like this

    const r1: { a: number; b: number } = { a: 10, b: 20 };

    const r2 = r1 satisfies { a: number };

    const r3: { a: number; b: string } = { b: "hello", ...r2 };

Another "fix" would be to avoid using spread operator and specify every property manually .

Both of these solutions are far from ideal, I agree.

---

I don't advocate TS in this thread though; I genuinely want to understand what makes row polymorphism different, and after reading several articles and harassing Claude Sonnet about it, I still didn't grasp what row polymorphism allows over what TS has.

As to the differences with TS... I think they're playing in similar spaces but the monadic do syntax with Purescript lets you use row polymorphism for effect tracking without having to play weird API tricks. In TS that's going to be more difficult.

(short version: in purescript I could write an API client that tracks its state in the types so that you can make sure you authorize before calling some mechanism. In TS you would need to design that API around that concept and do things like client = client.authorize(). Purescript you could just do "authorize" in a monadic context and have the "context" update accordingly)