Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

>My bignum library for Nim (not well tested yet): https://github.com/def-/bigints

>Complex numbers: http://nim-lang.org/complex.html

Ah, good! Glad to be wrong about that! It would be nice if Nim's reader could handle these numeric types transparently.

>How is the macro system primitive?

Well, I like to use macros to create new syntax, which AFAICT you can't do that with Nim. I'm used to using 'define-syntax' in Scheme, and Nim's macro system seems to be far less robust than that. I guess that's the price paid for non-homoiconic syntax.

I just don't see anything new and exiciting in Nim. :(



You're really very wrong on Nim's macros. It follows Lisp's defmacro tradition instead of Scheme syntax-rules/syntax-case, but that doesn't make it any less powerful (many would argue it's demonstrably more powerful). You are also dead wrong on syntax-rules/syntax-case capabilities, or maybe on what the syntax/AST is, if you think that there's anything they can do that Nim can't. Both systems deal with AST which means they both are unable to introduce new ways of parsing the code, only transform already parsed one. In (some) Scheme and Common Lisp you get access to readtable, which is the parser, but that's really a different thing. And even in Lisps it's not that popular: Clojure and Emacs Lisp disallow this for example.

Personally I favour pattern-based macros, like the ones implemented in Dylan, Elixir or Sweet.js (to show some non-sexp-based languages with such macros); but there is nothing "wrong" with procedural macros and they are not, in any way, less robust.

You don't have to be excited by Nim, but you should try to avoid spreading lies just because you aren't. Maybe a "lie" is too strong a word, but this statement: "Nim's macro system seems to be far less robust than that" is really very wrong and I wanted to stress this fact.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: