ну это много времени не занимает, да и весь синтаксис из экстеншонов все равно надо парсить чтиоб писать вот тут у вас такой-то экстеншон используется, а вы его не включили

нет, появляется локальное use SomeTrait

а всё перед этим уже есть в импортах

Foo.Bar.BazX
или
Foo.Bar.Baz.X

есть ли тут какая-то существенная разница?

Да

я тоже считаю что есть, и эта разница в том, что второй вариант удобнее, потому что
а) его можно раскрыть при желании
б) короче паттерны и конструирования с открытым неймспейсом
в) имена конструкторов проще, без какого-то мусора, навязанным проблемами языка

иметь в коде Nil, VNil, HNil, RNil, TNil это ужасно (на самом деле не очень ужасно, но как минимум это грязно, и это в хаскеле отторгает лично меня)

поэтому я давно использую duplicate record fields и называю все поля рекордов без всяких префиксов и суффиксов

Первое вообще напоминает издержки с++/java, где бьіли/есть int mClassMember или int _privateField

ждём -XDuplicateSumConstructors

+

Можно краткий пример, не сильно понимаю, как это

data X = X { a :: Int }
data Y = Y { a :: Int }

вместо

data X = X { xA :: Int }
data Y = Y { yA :: Int }

без DRF будет ругаться

понял

Сто॑ит ли писать сигнатуру вспомогательных ф-ций внутри where?

Для полного счастья еще NoFieldsSelectors осталось дождаться.

нет, но иногда приходится

Ну да, я имел ввиду кроме случаев, когда невозможно заинферрить

А почему нет?

а зачем? В локальных функциях сингнатура и так зачастую выводится, в том числе и человеком, лишняя сигнатура может захламить простой код и сделать его сложнее читаемым

больше кода это не всегда хорошо, как и меньше кода, код где на всех определениях есть сигнатуры не сильно лучше кода без сигнатур вовсе, должен быть какой-то баланс, когда человек сам решает, что вот тут сигнатура поможет, а вот тут никакого смысла в ней нет, но в болшинстве случаев она все равно не нужна