Hacker News Reader

Comment by beagle3 | Hacker News Reader

I've just read through the Nim manual. On the surface, it looks as simple as Python - but it is ridiculously deep when you look at all the template, macro, term rewriters, etc.

Whether or not you can make use of it without being aware of all those things remains to be seen. I suspect the answer is mostly yes, i.e. that one can use the nim ecosystem effectively without knowing all of that. (my answer for C++ would be "mostly no" - you need to really know everything about all the dark corners of the language to use the ecosystem effectively).

I'm trying to think of a good way to implement automatic reference counting with copy-on-write, e.g. for big arrays, but haven't come up with one yet. Could a Nim veteran kindly point me in the idiomatic direction?

View on HN

You cannot do these things easily currently since the assignment operator cannot be overloaded. There are ways around it, you can "fix" the broken builtin assignment with a TR macro, but since TR macros MUST not change semantics (you can disable them on a global level and code shall continue to work!) this is a bad idea.

How about doing something like:

    type refCounted[T] =
      val: T
      refs: int

    proc `v=`(var x:refCounted[T], var y:refCounted[T]) =
      inc(y.refs)
      dec(x.refs)
      if x.refs <= 0: destroy(x.val)
      x.val = y.val

    # use let so x and y cannot be assigned    
    let x, y = refCounted[string]

    # instead use x.v to assign and manage refs properly.
    x.v = y

using "let" would make sure all assignments happen through a blessed method (such as the ".v" assignment I defined above).

But to actually make it work, I would need to decrease reference on going-out-of-scope (as there a way to do that? maybe a python "with" style enter exit macro?).

And to make it easy to work with, there would need to be a way to pre- "incref" an argument before it is passed as an argument, and "decref" it after the function call return. I can probably write a macro that rewrites every function call with a refCounted arg so that it increfs() on the way in, decrefs() on the way out; or maybe have that macro on the callees instead.

Guess I'll have to try the different approaches and see what works and how efficiently.

I think that should be

    type refCounted[T] = object
      val: T
      refs: int

You could try a destructor for the object: http://nim-lang.org/manual.html#destructors

Hey I come from Python too and I just want to put out there both that Nim is a normal language - you can use it without templates or macros (you might end up using someone else's macro because some stdlib or library is implemented as one, but you don't have to write them yourself) - but also that Nim's macros are quite easy to understand!

They are just functions that take an AST tree, modify that AST or produce a new AST and return it. Its just normal Nim code working on an AST object. That's it! I wrote a small blog article about them when I first learned about them: http://blog.ldlework.com/a-cursory-look-at-meta-programming-...

I encourage you to conquer your fears!

Oh, I have no fear.

I was just comparing to C++ - where you have to understand how everything about templates and the STL works if you intend to understand the error messages produced by the compiler if you use STL. Or any library that interacts with STL containers. I heard things on this front have improved - I myself have left C++ for C a while ago.

C++ is a monstrosity. A common advice is "just pick the parts you like and stick to them". But it never works that way - as soon as you interact with 3rd party code, you have to deal with the parts THEY liked.

In comparison, my intuition says that despite all the dark corners (and if you read the entire manual, there are quite a few of them), that's not the case with Nim; Instead, if you treat it like a dialect of Python, you'll get simplicity close to Python; You'd only need to understand those dark corners if you plan to make use of them.

But I will need actual experience in Nim to find support for or against this intuition.

Hey I am just curious as to what you see as the dark corners of Nim?

Python is pretty deep too once you start digging with stuff like dir(), and various other introspection libraries.

Reply on news.ycombinator.com