re @vega: > 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
I come at this from the "big picture" and advocacy point of view. The details of how it would be implemented are obviously up to Araq and the core dev team. That said, IMHO: tweaking the parser during the parsing is not something that mere mortals should contemplate lightly... >From the point of view of expediency, it would be easiest to have all >available skins be part of the nim compiler binary [(see >compiler/syntaxes.nim)](https://github.com/nim-lang/Nim/blob/devel/compiler/syntaxes.nim). > One change I would make is to allow setting the parser name based on source >extension (with some order of precedence if there are two files with same >module names). >From the ease of extensibility point of view, on the other hand, it would be >beneficial to create a compiler plug-in system, so that different compiler >modules (frontends, backends, maybe even some other things) could be installed >via nimble. But that's a more complicated change, whereas I think Nim would >benefit from getting the skins idea out there ASAP. It's all about getting people excited. * * * re @dom96: > > 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. I thought of skins as something much more powerful than simply changing the scope parsing logic. I thought it could hook into the entirety of the parser logic, substitute keywords and operators, change the identifier style normalization function, raise errors if certain features are used, inject code, etc. After this feature is implemented, the Nim core dev team will not need to deal with the alternative / higher-level compiler frontends: other people will create them. This "pick your own syntax philosophy" approach will mean **Nim will have** **_everyone's_** **favorite syntax** (in its class of statically typed languages, at least), and that has the potential to make the Nim ecosystem _much_ bigger. Aside from altering the syntax of Nim the general-purpose programming language, I was even thinking of a pre-parsing step that would allow the Nim compiler to deal with any arbitrary DSLs. The "skin" (compiler frontend module) would freely parse the input source at compile time as any regular input file, and generate the corresponding Nim code for the next phase of parsing. So any syntax conceivable by the frontend modules devs would be turned into Nim AST. A simple example of this would be "Nim Server Pages" (analogous of PHP), where the file would be HTML-first with embedded high-level commands, and the pre-parser would turn that into Nim code that echo's the HTML and substitutes the code commands with Nim calls to the procs in the modules auto-imported by this skin. I got some other DSLs ideas in the works (c0m, d0c, etc)... **_Let a thousand DSLs bloom!_** * * * re @mmierzwa: > syntax wars will not be ceased in peaceful Nim world, they will be drag > inside Nim world Conflicts are worse when there is a win-lose situation: one way wins and all other ways lose. Imagine what would happen if Unix could only have one text editor... If everyone can have it their own way when it comes to syntax skins, it's win-win, so there is less conflict. > If I see two programs in Nim written in different syntax it is not very > different situation for me if they were actually written in different > languages. And so if I see program written in F# it does not help that I know > VB and C# and all three are compiled to CLR. OK, let's look at this analogy. With the advent of powerful syntax skins, Nim would become two separate things: # Nim-the-platform, crudely analogous to .NET, and # Nim-the-language, crudely analogous to... [Boo!](https://en.wikipedia.org/wiki/Boo_\(programming_language\)) Imagine if .NET wasn't a big corporate platform with a humongous built-in audience, but (like Nim) a struggling upstart with many more popular competitors - and the only language available for it was Boo. Don't you think having C# (C/Java-style, which has the largest market share among language styles), F# (ML-style), VB, etc has benefited .NET compared to if it was only Boo, and people who like other styles had to pick a language outside the .NET? We have to keep in mind that people voluntarily choose to use a given programming language, and to contribute code for you to see / modules for you to use. This is more true for Nim's audience than .NET's, as Nim is a grass-roots project without a large corporate foundation. Some existing languages had more of a built-in audience (C#) or a authority (Go) behind them, but Nim doesn't have that privilege: it must climb up from its current [129th place](https://archive.is/KYBa7#selection-2621.172-2621.177) by persuading people to use it, and offering them the most comfortable programming experience. Nim-the-platform can achieve great things and liberate the world from the chronic turmoil of C++, the ascendancy of Java / .NET, or the bloated misery of dozens of different runtimes in the userland! Nim-the-language would lose its monopoly on the Nim platform, but in the long run it would gain a lot more. > Once there are many concurrent styles we will have to specify one official, > otherwise you would have to use many in documentation. Of course. The vintage Araqian Nim would always be the flagship, like the Java language on the Java platform. > There are plenty of people who choose language depending on task > requirements, team, environgment etc. They do not want to study all subtles > of a overcomplex language. They want to do their job. Clear rules, easy to > pick up syntax are in favour then. Yes, companies and projects would probably want to choose one language from the multiple offered by the Nim platform, but it should be their choice to make. * * * (Sorry that some of my replies are out of order. I'll catch up with more of the replies later.)
