[naasking]

I'm no longer convinced of the need for row or record polymorphism. It encourages passing around types that have no clear domain or purpose, so I think it inhibits understanding in general. Do you have any examples where it's indispensable?

[gpderetta]

I don't think it is indispensable, I think it is convenient and still better than what is done today were types without clear domain and purpose are already passed around.

At the very least with row polymorphism, a function can declare which subset of the type it actually care about instead of taking an unwanted dependency on the whole blob.

In particular I'm considering the scenario were a large application (or better a collection of applications) evolve without a central plan and messages tend to grow to accommodate orthogonal requirements (the alternative is splitting the messages, but it has performance, complexity and organizational overhead).

In theory the alternative is message inheritance, but in my experience it has never worked well and it is very hard to retrofit anyway.

[naasking]

> At the very least with row polymorphism, a function can declare which subset of the type it actually care about instead of taking an unwanted dependency on the whole blob.

This is the argument I no longer find convincing. Do you have an example where this is so much clearer than alternate, simpler ways of doing it?

For instance, in principle you could easily rewrite a function that works on a record with 3 fields to just accept 3 parameters. The only additional "burden" is that the caller has to pass in those 3 fields, where before they could just pass in the record.

[int_19h]

Having it as a single parameter precludes the mistake of passing unrelated values, though.

[naasking]

The row typed function is also less reusable for that reason.

If you have two fields of compatible type such that you can confuse which one to pass as a parameter, then it's likely you're not making enough domain specific type distinctions that would disambiguate these fields.

If these fields were really compatible domain specific types, then it's more likely you would want to be able to use that function with both fields at some point. Row typing then either hinders this reuse (not good), or requires you to refactor to encapsulate both fields in a new record with compatible fields and pass that in (maybe good?). This is code you wouldn't have to write without row types.

But as I said, I would like a concrete example to discuss if anyone has one. Speaking in abstract like this isn't likely to be convincing either way.

[marcosdumay]

Nothing is indispensable as long as you have a Turing complete language. That is a really bad mindset to use.

Anyway, are you complaining that the types are abstract? (That is as bad a complaint as it sounds.) Or do you have something different in mind?

[naasking]

You're taking indispensable too literally. If you have to commonly write 1,000 lines of code without a feature, but the feature permits you to to reduce this to 1 line of code, I'd consider that to be pretty indispensable.

Where the indispensable line is is debatable, hence my request for an example.