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
> 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
**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
@dom96 Thank you very much for your reply. Having an open and transparent
pathway to 1.0 is going to be so important for the community and for fostering
adoption. Thank you for all of your efforts. I just had my new Nim book arrive
in the mail this week. Can't wait to read it!
> #? braces
Thank you god this exists. Best thing I learned today.
@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
@dom96, Very interesting! Any hints that you may provide on the timeline for
the 1.0 release? I know that there are a lot of people who are waiting until
1.0 hits before seriously looking at Nim and so this is quite a big deal. If it
is coming very soon then that could be quite interesting. Is
> This thread scares me as a new Nim user
This brainstorming session is long expired.
* * *
Summarizing Araq's verdict with quotes from above:
{
* "Skins were part of my original Nim 'vision'."
* "I now think syntax skins should be an editor feature, not a compiler
feature, so relax."
Honestly, I'm not for or against skins one way or another - I see the value and
the potential pitfalls as described by various folks. What is more interesting
from this thread is the potential ability of Nim to allow developing such skins
in so called user-space. If I could write a completely
If Nim main dev wants to implement a new feature, and this feature uses a token
(or a whole expression) already used by a skin. How will you prevent the
breaking of many existing code ? (Sorry if the english is not very good)
I've used to speak curly braces before Nim, and I agree with @allochi. Nim
syntax is nice for the most part. I don't think syntax is something worth
discussion as long as it is consistent. On the other hand, splitting the
community to different camps is likely to weaken (or bury) the ecosystem.
Thanks @dom96, I hope I didn't offend anyone with my post.
Simply put, I don't care which syntax Nim adopt, if you guys decide tomorrow to
make it Cish or Rubyish, I'm fine, as long as there is one syntax that is
consistent and readable.
So far for me Nim standard syntax is quite expressive
> This thread scares me as a new Nim user
It scares me too. Things like
[this](https://github.com/nim-lang/Nim/issues/7124#issuecomment-359458919) make
me want to change the language. There is a limit to how many different ways it
should be possible to do the same thing.
While Araq seems to
This thread scares me as a new Nim user, for all the reasons mentioned before,
I don't wish for Nim to have multiple syntaxes.
I also come from a C style kind of languages and I love it, and I hate the
indentation style, this is one of my problems with Python (one, there are
many), but I
How about Racket-style #lang pragmas?
That way you can use any syntax or semantics you want in a given module, so
long as your "lang" definition contains a parser
Hi I would like to add another voice of reason to this question. As Krux02
says, the consequence of this permissiveness is that now we can't do something
as simple as refactor some variable name with a find and replace. Or go find
all its occurences in the source code. So Nim project does not
> Skins were part of my original Nim "vision".
Nobody's perfect
That vision is consistent with the style insensitive naming, which I'm also not
crazy about.
> There is a big difference between features that cost us manpower (cough
> concepts) and > features that are mostly free of
Just to chime in on this: I see nothing wrong per se with TMTOWTDI
(theres-more-than-one-way-to-do-it) but a syntax skin is a hard sell
considering the main priority should be getting that v1.0 release out now. I'm
a fan of the principle of least surprise - programming is hard enough to get
> Multi-syntax is harmful for such small amount of developers.
I think this is an important point. At the current community size, an
alternative syntax is a bad idea. That might change if Nim were to 'take off'.
For example, in the nascent D community, Tango/Phobos split may have been a
fatal
RedFred is right, Nim core developers have to focus on important things, like
stability, documentation, and making the language complete (Nim is not a
complete language, yet).
Nim's Python-like syntax is nice and there is no way to change it, because Nim
in Action is finished. If you want to
@lltp
> You have a look at it and you see a perl-ish "Nim" that you spend weeks to
> learn
No, with skins done right, you wouldn't: the Perl afficionado would have used
an editor which supports a perlish skin for AST display, but saves the source
code as Nim proper (the default skin). You
I agree with @scriptkiddy.
I think syntax skins are a complete waste of time and resources when stable
language v1.1 and better documentation will do far more for adoption.
I have nothing to add to the arguments I've made for why I think turning Nim
into a platform that's not monogamously married for life to a single language
frontend would broaden Nim's appeal.
I would just like to express my utmost respect for all people who've weighed in
on this discussion,
@RedFred: I think you really summarize this nicely:
> Programming languages should allow programmers to express themselves in the
> way that the programmers see best, not try to force them to adapt to the
> language.
But where you see a huge improvement for a lone programmer who doesn't care
I'm not a fan of significant whitespace in programming but I was happy to
overlook this with Nim because of all the other language awesomeness. I don't
think indentation syntax is a show-stopper when trying to learn a new language,
I don't think people will ignore Nim's flexibility and elegance
The skin is a language's personality. To copy other personalities is no
personality.
IMHO, language-wise, concept of skin is very exciting.
Community-wise, it's better to focus to other area instead of syntax.
Personally, using the brackets easier for navigation since I'm using vim, I
just press '%' and I can immediately navigate to the end of the pairing bracket.
I said this earlier in the thread, but I'll reiterate:
I think this idea is a waste of time and resources.
Hear me out. Code is read far more often than it is written. This is objective
fact. Therefore, a programming language should be optimized for easy reading. A
user with a beginner level
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
IMHO skins are cancer. Problem of Nim is that it is trying to be
best-everything all at once. Result of this is over a decade of unstable
language which did not reach 1.0 yet. Yes, we all have our own tastes. I
dislike some stuff in nim as well. I can get used to them if language is
solving my
@libman > The modules they write in Rust or whatever will not benefit Nimland.
But if there's a Nim syntax variant / "skin" that they like, then they're still
on our side, and their modules are a part of our world.
I disagree. Rust and other programming languages are not the enemy, or
Just remark. In SQL Server for instance you can design query graphically but
everyone (in my experience) just write it in text. I am trying to say that it
would not be easy to go to higher level of abstraction. Graphical languages are
not very popular. Human is a beast which thinks rather
@scriptkiddy:
> I personally do not like the idea of syntax "skins" at all. It is actually
> one of the biggest issues I have with Javascript. When I'm looking at a
> project written with es2015 vs TypeScript vs CoffeeScript I have to try and
> imagine how it would look in regular old es5 just
Maybe we should think of it this way:
Java is referred to as a ["software
platform"](https://en.wikipedia.org/wiki/Java_\(software_platform\)), which
consists of the Java language (a flagship, but with other languages available),
javac compiler, a huge ecosystem of libraries and tools, etc.
I would like to just mention that for the programming language vala, the same
thing has already been done. Here is Vala with Python syntax:
[https://wiki.gnome.org/Projects/Genie](https://wiki.gnome.org/Projects/Genie)
While I don't want to drag a war about begin/end/{}/indentation in this
I personally do not like the idea of syntax "skins" at all. It is actually one
of the biggest issues I have with Javascript. When I'm looking at a project
written with es2015 vs TypeScript vs CoffeeScript I have to try and imagine how
it would look in regular old es5 just to get an
> I find it remarkable that no IDE that I'm aware of supports this already.
vim has some sort of rewrite rules you can define, for example i changed some
of python syntax in my editor
also, when you edit .json files in gvim they look more like json5 files: vim
omits keys' and values' quotes
I think that also the question is whether we (you rather) are making practical
language or academic one. I am not sure if both can be successfully combined
(although such approach worked for pypy they say). Endow language with all
shiny, "it is how it should be" etc. concepts, which can by the
I like the idea of "skins", but I think to sell it to people one would have to
change their idea of what a "programming laguage" is.
In the case of web pages, we have three kinds of files: CSS, (X)HTML and XSLT.
They define (in that order) presentation, content/structure and transformation
of
I implemented this as a "proof of concept" really, hence no documentation and
no announcement. I think it solves the problem on the wrong level. "show me the
code with/without braces" should be an IDE feature, then it only causes
problems when pair programing . I find it remarkable that no IDE
**spip:** _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._
Yes, but it has always created lots of pain points for tooling. More recently,
OCaml has been using towards using PPX rewriters
> 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
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
Seed7 have fully plugable syntax afaik
[https://en.wikipedia.org/wiki/Seed7](https://en.wikipedia.org/wiki/Seed7)
To my knowledge, OCaml already has this feature to offer different syntaxes to
the users, varying from enhanced
[OCaml](http://camlp5.gforge.inria.fr/doc/htmlc/revsynt.html) to
[Scheme/List](http://camlp5.gforge.inria.fr/doc/htmlc/scheme.html) or even
[user
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](http://pypl.github.io/PYPL.html), Python has about 15% market share, and
other [off-side
To really mess with our minds, do you also have an optional skin translation
like
skin (one syntax) `->` AST `->` skin (another syntax)
Secondly, if the intermediate AST syntax was exportable (to file), does that
give Nim a platform-independent representation (assuming it includes the `when
> Isn't the braces "skin" supported?
OK, wow, I see that
[compiler/syntaxes.nim](https://github.com/nim-lang/Nim/blob/devel/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
So is this:
skin (parsing?) `->` AST intermediate syntax `->` backend (c, c++, ObjC,
JS, LLVM, ...)
Isn't the braces "skin" supported?
#? braces
proc main() {
echo("Hello");
}
when (isMainModule) {
main();
}
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](https://www.reddit.com/r/nim/comments/5pjf3v/nim_makes_slashdot_new_release_of_nim_borrows/)
to [Nim making
51 matches
Mail list logo
