| presently), whilst requiring a pragma means either making the parser | code really messy "everywhere" there's a comma, or having lots of | duplication there. I don't understand this at all. The standard way is simply to parse the comma(s) always, record the presence of trailing comma(s) in the syntax tree, and then complain/reject in the renamer if the extension is not enabled. That does not make the parser really messy anywhere, I think. You might want a new HsSyn data type for "list with possible leading or trailing commas": data HsCommadList a = HCL Int -- Number of leading commas [a] Int -- Number of trailing commas Simon | | And giving it some thought, I'd argue for going more or less the same | route with regards to patches for a pragma. I.e. add an initial patch | that adds the pragma itself & leading commas for imports/exports, and | then submit a bunch of small commits to augment the pragma to | phabricator, and update the Wiki accordingly. | | | In any event, I'll have to get everything working, so you'll have | plenty of time meanwhile to decide on this issue. | - -- | Alexander | alexander@plaimi.net | https://secure.plaimi.net/~alexander | -----BEGIN PGP SIGNATURE----- | Version: GnuPG v2 | Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ | | iF4EAREIAAYFAlQhIZQACgkQRtClrXBQc7V2AwD/SkAHL0fIXhP3DDmI0i7IipeJ | 8Z1JT0k8YqyssJtq6YgBAIB4betQXTHMDt0IGu+OLty6A6iGp2WZQ4kRNlx1lVWa | =1xbA | -----END PGP SIGNATURE-----