👋 @kindaro
Thank you for raising your pull request.
Please make sure you have followed our contributing guidelines. We will review it as soon as possible!

Reviewer: Please verify the following things have been done, if applicable.

• CHANGELOG.md has been updated
• Configuration docs in README.md have been updated
• fourmolu.yaml updated to stay in sync with config in README.md
• Tests have been added

Thanks! Can you make the code and config a bit less opinionated? A simple bool for the config, and rename the args to whenUnicodeOtherwise...

This is cool, and I'm interested in trying it on some of my smaller personal projects. But I agree with @brandonchinn178 that more neutral language would be preferable, seeing as the current wording doesn't necessarily reflect all maintainers' views on unicode syntax.

Like so?

Perfect, thanks! Can you follow the instructions in CONTRIBUTING.md to update docs + tests for your new option?

@brandonchinn178   There is no such file in this repository. Can you link me to it? Better even, tell me what you want me to do.

Sorry, DEVELOPER.md

I think this might actually work best as a ternary option, with the values always, never and detect. Where detect will output unicode if and only if the UnicodeSyntax extension is enabled, similarly to what we do with ImportQualifiedPost. I feel detect would be the sensible default.

Is there any particular reason why this doesn't cover all unicode syntax e.g. forall/``∀`?

I don't mind if the constructs currently implemented are the only ones you care about! But if so, we should open a follow-up issue tracking the fact that we should implement the rest.

• Change the metaHelp text.
• Detect the UnicodeSyntax extension.
• Add missing Unicode symbols.

So, as George says, ImportQualifiedPost is automatic. And it does not have any command line flags to it. If the extension is enabled, the syntax is used — easy!

Why then have a command line option for UnicodeSyntax? Maybe we should hard-wire it in the same way as ImportQualifiedPost? You want it — you switch the extension on (you have to anyway, lest parse errors befall you). You want none of it — you switch the extension off.

That makes sense to me! Have you checked to see if this is something Ormolu wants? If so, it would be better to make the change upstream instead.

I see little harm in it being configurable. But I'm not that bothered either way. If someone has turned on the extension, it does seem odd for them not to want unicode output. Then again, what if UnicodeSyntax is added to GHC202*?

And I agree that if we're going to go with the non-configurable version, then it's worth at least mentioning upstream.

I see little harm in it being configurable.

That's fair. I think this is something Ormolu would be interested in anyway, so I think we should wait and see how that conversation pans out. If they don't want it, we can merge it here. If they do, we could think about making an option to forcibly turn it on.

They do not want it, so we are back here.

I say there should only be two options: «automatic» and «never». If you try to add Unicode syntax to a module where the extension is not enabled, there will be a parse error, so it is pointless to add an option «always». Agreeable?

If you try to add Unicode syntax to a module where the extension is not enabled, there will be a parse error, so it is pointless to add an option «always».

My concern was that a user's environment might be set up such that Fourmolu doesn't know the extension is active. But in that case, I guess they can just pass the extension to Fourmolu explicitly.

Personally, I dont think we need any option. If someone wants to disable it for a particular module, they can turn off the extension with NoUnicodeSyntax

I have a weak preference towards the ternary option, but I don't want to bikeshed. I'm happy with no option if that's what others prefer. We can always add options later if someone has a use case.

1. It makes sense that fourmolu should behave exactly as ormolu with some «compatibility» configuration But ormolu declined to add this feature. Therefore, we must have at least a setting to switch this feature off.
2. The extension UnicodeSyntax can be supplied to fourmolu with a specialized option, which will result in this feature being switched on for all modules. Therefore, the option to switch this feature on is redundant.

I shall add settings «never» and «automatic». Hopefully soon.

Another argument for giving a flag to switch the extension off: currently, if you enable ImportQualifiedPost, fourmolu will format all your imports that way — then, if you remove the extension, it could not parse the code anymore! So, there is no way back, even though in principle fourmolu can as easily format the imports back.

By extension, we may want to set the UnicodeSyntax extension on with an appropriate option to fourmolu and yet ask it to write ASCII syntax. So, we cannot say that the option «always» is not needed either. Enabling the extension is different from setting the option to «always».

Hey I have been busy but finally — rebased, added a three way option, and automatic detection of the extension. Ready for review!

Also, it looks like there are test failures. The biggest one being that fourmolu.yaml should be updated to include unicode: never (being that fourmolu.yaml represents the configuration to match ormolu's style)

@brandonchinn178   Done!

Seems like there are still some test failures

Yes, I changed some white space in input.hs and forgot to refresh the output files because I thought it should not make difference but turns out it does.

It is the small things that will be my undoing.

I rebased, there are no test failures, changelog.d updated, ready to ship.

Thanks!