In my persistent experience as a Nim advocate, various issues of superficial syntax preferences continue to come up - literally on a daily basis...
In the r/nim link to Nim making Slashdot, a commenter summed up the /. comments as follows:
And the discussion turned into a holy war between White Space Knights, Curly Braces Commandos and a few Begin/End Revolutionists
Some people are addicted to C-isms, some to useless "end" lines, etc - and they won't even consider a language that does things differently. I think the Pythonic "off-side rule" syntax is objectively superior in saving keystrokes and screen real-estate while also encouraging correct practices and improving readability - but I also believe in the mantra that "the customer is always right". ;)
And so I would like to re-introduce the topic of Nim Syntax "Skins" to this forum, first by summarizing what I've heard about this idea so far.
A year ago Araq wrote:
The initial design of Nim was envisioned as an AST with multiple "skins" so programmer A can have it his way and still use programmer B's module directly rather than having to interface with a completely different programming language. And after 10 years this simple idea is still ahead of its time with the closest implementation for this idea being .NET. [...]
The discussion of syntax skins was raised briefly several times on IRC. Here are some of my musings:
We should all spare Araq our syntax complaining. Everyone should just make their own Nim "skin". I've been pondering lots of crazy ideas for this.
Having a "skin" that uses C-like curly braces without one-off rule would like double Nim's appeal overnight.
If Nim was to have [an alternative, even more Pythonic] "Pythonic skin" and appealed to Python programmers, it [Nim] would be more popular by now.
I agree that braces are useless, but more syntax "skins" => more users => more contribs => more sushi.
Nim can be the ideal programming ecosystem, but no one syntax skin can compete with Python and Rust at the same time. There could eventually be an even more high-level way to code Nim. Implicit var, implicit type conversion, much syntax sugar, etc. But that's not a priority for now.
My Nim skin would also allow avoiding repetitive keywords, like = assignment operator defaulting to var, ≗ to let, and ≛ to const.
Unfortunately, I do not have the depth of knowledge to be the first programmer to implement an alternative skin for Nim. But I think anyone who breaks the ice on this issue by creating a curly brace skin for Nim would bring a lot of added attention and contributions to the Nim ecosystem.
That would spark a marketplace of competing syntax philosophies, on which programmers can "agree to disagree" - all to Nim's benefit! :)
Isn't the braces "skin" supported?
#? braces
proc main() {
echo("Hello");
}
when (isMainModule) {
main();
}
Isn't the braces "skin" supported?
OK, wow, I see that compiler/syntaxes.nim has recently gained this surprise, but I didn't see it announced or documented anywhere...
Araq is always 11 moves ahead of everyone else. But this is an advocacy issue, to answer people whining about Nim's syntax - keeping something secret isn't how advertising usually works. ;)
skin (parsing?) -> AST intermediate syntax -> backend (c, c++, ObjC, JS, LLVM, ...)
That's the idea.
We should have tutorials showing how to fork and tweak Nim skins and get people excited about this possibility. Each skin will appeal to a different target audience and encourage them to be a part of the common Nim ecosystem, sharing the same nimble packages, etc.
There is a design problem in the FLOSS ecosystems today: the bloat caused by the proliferation of different incompatible runtimes. This is especially bad among scripting languages - since everyone wants to use their favorite, usually for very superficial reasons.
One guy writes: "I must have compilers or interpreters for 30 languages on my machine. Maybe more." Wow! Some people don't see bloat as a problem, but it is. That's a lot of duplication of effort, added complexity, added learning curve for someone who wants to understand the whole system, and added attack surface for security vulnerabilities!
In the Microsoft ecosystem there's CLR.NET, and in Android (and many other corporate cathedrals) there's the Java platform. People who don't like the Java language can use Kotlin, Groovy, Scala, Clojure, etc - without fragmenting the ecosystem and causing additional bloat.
I see Nim as the ideal userland language for a well-designed lean system, a future copyfree answer to Ubuntu desktop or Android. But syntax arguments are perhaps the biggest barrier to being able to get everyone on the same page for such a project.
Secondly, if the intermediate AST syntax was exportable (to file), does that give Nim a platform-independent representation (assuming it includes the when defined(....): code)?
Thirdly, if this ever became reality, documenting and tracking changes to the AST would be very important.
Ideas need to be prioritized.
Getting the Nim syntax skin idea out there would be a very significant advocacy advance to help put more fuel in the tank. According to PYPL, Python has about 15% market share, and other off-side rule languages hardly register. Lots of people who previously skipped Nim because they're allergic to the indentation syntax would suddenly jump on board. As this skinning feature would be pretty unique to Nim, it would be news-worthy on the general programming sites. Instead of being on one unpopular side of the syntax Holy Wars, Nim would make news as the peacemaker that makes those wars obsolete!
Auto-converting from one syntax to another, caching AST for cross-compilation, and other ideas - possibly useful, but not potential game-changers.
To my knowledge, OCaml already has this feature to offer different syntaxes to the users, varying from enhanced OCaml to Scheme/List or even user defined.
Even in C, you can
#define begin {
#define end }
In fact, any language supporting macros allows a type of syntax variation. I'm not sure this is really a vending feature, nor desirable. If any programmer is able to favor a personal syntax style, how to you deal when they work on the same source file?
I'm leaving in a bilingual country, and I've spent my afternoon today splitting a bilingual document (you see, the kind with two columns, one in French and the other one in English) because a person with disabilities was not able to read it with her aural browser. Mixing languages in the same document is not always a smart idea...
Wow, didn't know about syntax skins. This feature needs to be documented :-)
What do you think about the possibility to specify syntax skin described in external nim source? This can be used like the reader macros in Lisp or like readtables in sweet.js
Lots of people who previously skipped Nim because they're allergic to the indentation syntax would suddenly jump on board.
I'm not sure that this is true. In fact, I always feared that people who love indentation syntax might end up not using Nim because of the possibility that code may use braces or begin and end. I don't think it's that simple to sell the language to brace lovers.
Plus, there is a lot more about Nim's syntax that makes it Python-like. In C you would write && instead of and. This will definitely upset some people too.
So let's think about this carefully before selling it. There is already plenty of people who see style insensitivity (fooBar == foo_bar) and jump to the conclusion that it sucks. This might be similar, it is also a kind of "style" insensitivity actually.
@Libman Thanks for the clarification
@dom96 I though that 0.18 is coming first.
Anyway, I hope to see you guys in FOSDEM in Brussels, and by then I probably can share some thought, meantime, I'm trying to use Nim on daily basis and get to understand it better. it's amazing how fast I can complete tasks in Nim.
I would also like to contribute to Nim base code and compiler in the future, so maybe when we meet in Brussels you can guide me on how to be an extra hand.
#? braces
Thank you god this exists. Best thing I learned today.
PRE PRO CES SORS
We have awesome examples like Pug Stylus Coffeescript, but our lang is already compiled, so it easiest things evar, just make preprocessor configuration (in yaml file would be nice) available for user custom schemes, which can be defined global, or shipped with a project
so code can be compiled to whatever or just plain simple Nim
Our big advantage is absence of Webpack, thing from hell, which is always attempting to break your bones, sometimes it ending up with success ~_~
This is an interesting thread, and I didn't know syntax skins were such a near-feature in Nim.
I'm very attracted to the idea - I think that syntax is actually very important, but also a personal preference. There's not a lot to be gained by arguing about it. I accept that some people like curly-braces, and it makes code easier to read for them, but for me it makes it noisy and more difficult. Abortions for some, miniature American flags for others.
I like Nim's syntax a lot, but there are things I might change (tabs!, maybe assignment to ":" or "<-" so "=" can be used for comparison).
BUT how are people supposed to learn Nim if all the code examples use different syntax? It's already a little tricky with Nim's syntax flexibility, macros, and sparse code examples. Newbs like me approach languages syntax-first, and I don't think I could have picked it up at all if the syntax varied wildly from example to example.
Some sort of Nim syntax translator in IDEs would obviously be part of the answer, but what about reading through code on Github and other parts of the web? A browser extension to translate on the fly?
The mind boggles.
reading through code on Github and other parts of the web? Simple convention — do not upload to public spaces your preprocessored code, dat simple
btw m$ with their .NET CLI compliant languages - tried to get similar approach, but it is a m$, so they ended up with Mono monopoly, heh
The idea of having a binary AST format is finally lifting off in the vast swamps of JavaScript...
Whether this can benefit languages that compile to JS is a separate discussion, but it also has similarity to the Nim "Syntax Skins" idea. Break up the compiler into separate programs (or make it executable in partial compilation modes): a front-end that generates binary AST, and a backend that converts it to C or JS. It would then be possible to fork the front-end to create "sibling languages" for Nim that share the same module ecosystem and backend.