Multiple modes in version 2

[archnim]

Hello world. Nim tries to provide the best code style for everyone. But code style is still the main obstacle for many people. Many abandon the language without even giving it a real chance, just because they hate case insensitivity or python-like syntax. Even between those that are already nim fanatics, many aren't satisfied of Nim's code style. There are often posts in the forum where people complain about that (A recent example here). It's not possible to satisfy everybody by just maintaining or changing the current syntax, because it's hard to find a consensus .

So my proposal is to provide "syntax modes" in Nim. These modes could allow tabs, curly braces, case sensitivity, and much more. We could even add support for mode classes, that will regroup several modes together. For example the "c-like" mode would activate several simple modes to provide a c-like syntax.

We should be able to activate modes in a module, or an entire package very easily. We already have modes in nimscript. I imagine something similar, at the beginning of each module, or in the file "package.nimble.

I think that, such a construct could make everybody appreciate Nim whatever are their style preferences.

[ynfle]

Would that not lead to more fragmentation and unnecessary overhead for the upkeep? We already can do we every we want with style. How will it help to have options?

[archnim]

@ynfle, I understand your position. For me, the current Nim syntax is already good. But case sensitivity seems to be very important for some people. It even prevents few people to switch to Nim, and our community is currently divided about whether or not, we should remove insensitivity. The problem is that, removing it could cause huge reverse-compatibily issues.

So I think that case insensitivity can stay the default mode, and we can enable sensitivity in a module by adding something like "Modes.CaseSens = true" at the beginning.

[Clonkk]

I don't think adding a non-negligible amount of additional development effort and maintenance simply because some people cannot adapt to simple syntax change or configure their IDE properly is a very good idea.

• Multiple syntax cause non uniform style between codebase which makes reading Nim code harder because the same thing will be expressed differently.
• Syntax is not the limiting factor for Nim's adoption; the only people who whine about syntax are the people who haven't tried to actually develop in Nim. So I doubt it would yield any benefit.
• In fact ,NIm used to support curly braces syntax as well as indentation based syntax and eventually dropped curly braces syntax; it was more work for little to no benefit. The trade-off of supporting one syntax vs multiple syntax was evaluated and considered not worth the effort.

[archnim]

You are absolutely right, @Clonkk. I hope it wouldn't be that hard to implement my idea. I think that, some macros should do it. But if there is no simple way to implement it, and if it can become a distraction for does who maintain the code, then the idea must be abandoned.

[c-blake]

If it helps @archnim to track down old discussions, the name Nim used for its initial attempt at this was called "syntax skins" (see, e.g., version control history of compiler/syntaxes.nim). I don't think it covered what now goes by "--styleCheck:error", though. And even --styleCheck:error will not allow let _a = 1 or let aB_ = 1, etc. So, there are a few issues that overlap in the human taste dimension enforced in different places in the compiler.

[dom96]

We've had this, it wasn't used very much though and afaik we got rid of it. Personally I don't think it's a wise move to reintroduce it.

[archnim]

Ok. I think we should forget it too.