Який прогрес у записах Haskell?

Нещодавно я ще раз натрапив на питання записів Haskell, зокрема на унікальність назв полів. (Це біль ...)

Я вже читав Пропозицію щодо записів у Haskell від SPJ та Greg Morrisett, але останнє оновлення було у 2003 році.
Інший документ під назвою Lightweight Extensible Records для Haskell від SPJ та Mark Jones є ще старшим: це з семінару Haskell в 1999 році.

Тепер мені цікаво, чи досяг успіху процес надання нових записів Haskell.
Хтось щось знає про це чи хтось може вказати мені на деяке подальше читання?

haskell language-features

— mmh
джерело

Мені також відомі записи в Haskell, але це не показує дискусій про різні підходи.

— ммх

Усі згодні з тим, що поточні записи погані, ніхто не погоджується, що саме робити. Іншими словами, бізнес як завжди. Якщо ви хочете додаткового читання, то, безумовно, не бракує нескінченних дискусій з цього питання, але я зараз не встигаю викопати посилання ...

— CA McCann

Можливо, вам пощастить запитати у списках розсилки.

— Rufflewind

Мої дві копійки.

Вірите чи ні, Haskell занадто багато використовується, щоб дозволити кардинальні зміни з існуючим програмним забезпеченням. І складно додавати записи, не порушуючи важливу частину мови.

ОНОВЛЕННЯ: BTW, я думаю, що записи - це хороша нова функція. Мені подобається найбільше, не маючи членів імен, що забруднюють глобальний простір імен.

— Чжень
джерело

Чи можете ви уточнити, що було б порушено, додавши записи? Чи кожна популярна пропозиція передбачає щось порушити?

Оператор з точкою (скласти) буде використовуватися в більшості пропозицій, тому: a.bбуде інше

— Zhen

Інша проблема полягає в тому, що якщо ви додасте нову систему записів, ви можете позбутися від поточної, яка була б переломною зміною, або мати дві системи запису одночасно, що було б безладом. Я думаю, що a.bпитання є менш важливим, оскільки A.bвже означає щось відмінне від A . b(завдяки модульній системі). Впевнені, що це зламана зміна, але це не особливо погано.

— Tikhon Jelvis