Live data from Hacker News

What makes Nim practical?

hookrace.net

81–90 of 132 posts

Re: What makes Nim practical?

#81
post #57
post #18

Earlier quoted context omitted.

As unwind suggested, they just get transformed down to global functions with unique names. Here's the actual C code generated: https://gist.github.com/def-/0fe87bf1d35102c62d3b#file-nest-...

What about variables nested within these functions then? Is scope enforced? i.e. you can reach back to variable aa in function a() from nested d() but can't reach variable dd in d() from a()?

I have no idea how it actually works, but it would be easy enough to implement by having nested functions take a parameter that's a pointer to a structure containing the variables that are in scope in the outer function.

In your example, it could be something like this:

    struct variables_in_a_that_are_visible_in_d {
        int aa;
    };
    
    void d_nested_in_a(struct variables_in_a_that_are_visible_in_d *ascope) {
        // Variable dd, not accessible from a
        int dd = 42;  
    
        // Increment a's aa
        ascope->aa += 1;
    }
    
    void a() {
        int aa = 0;
    
        // Pack up variables for d()
        struct variables_in_a_that_are_visible_in_d ford;
        ford.aa = aa;
    
        // actually call d)
        d_nested_in_a(&ford);
    
        // Unpack after calling d()
        aa = ford.aa;
    
        // Continue with a()
        // ...
    }
    
I'm a little surprised people are so hung up on this. They don't call C "portable assembly language" for nothing. If it can be done compiling to native code or some virtual machine assembly language, it can be done compiling to C.

Re: What makes Nim practical?

#82
post #77

Earlier quoted context omitted.

I think it is a matter of what is safe . While Ada doesn't provide the parallelism safety mecanisms from Rust, is is pretty much a safe systems programming language, specially the SPARK dialect. And I do conceed that using RAII or memory pools is a bit more cumbersome than in Rust. EDIT: Forgot to add that for me systems programming safety has been for a long time what Modula-3, Oberon and Ada offer. Only recently it…

Yeah, Ada/SPARK is safe too. But as I understand it achieves that by removing deallocation (from a single untyped heap) entirely, which is pretty limiting, though sufficient for a lot of embedded work.

Yes in SPARK's case.

In general Ada code, deallocation is considered unsafe and requires specializing the Unchecked_Deallocation() procedure. This is because Ada 83 allowed for optional GC.

In Ada 83, the safe alternative was to use memory pools.

With the newer revisions, support was added for RAII and Ada the ability to define custom refereced counted data structures, similar to how they are doing in C++.

So speaking of Ada 2012, you can get Ada's safety in terms of contracts, data types, numeric ranges, constrained types, access types (Ada pointers).

For heap related safety, it is possible if RAII, memory pools or RC access types are used. But like C++, this is one area where the compiler doesn't force the developer to use it.

Re: What makes Nim practical?

#83
post #48
post #21

Earlier quoted context omitted.

Nim isn't compiled to C in the same way that, say, Coffeescript is compiled to Javascript. Nim's compiler converts the AST into an intermediate representation that can be compiled to several backend. The primary backend is C source code, but it also supports outputting Javascript (experimentally) or interpreting the intermediate representation ala Python. The difficulty of developing the IR -> C transformation certai…

Your example isn't exactly true. Clang and GCC both do tail call optimizations. Compiling language functions to C functions doesn't 100% preclude you from TCO. http://david.wragg.org/blog/2014/02/c-tail-calls-1.html

See also: http://www.pipeline.com/~hbaker1/CheneyMTA.html

It looks like work/research in this area has been going on for at least ~20 years.

Re: What makes Nim practical?

#84
post #57

Earlier quoted context omitted.

What about variables nested within these functions then? Is scope enforced? i.e. you can reach back to variable aa in function a() from nested d() but can't reach variable dd in d() from a()?

I have no idea how it actually works, but it would be easy enough to implement by having nested functions take a parameter that's a pointer to a structure containing the variables that are in scope in the outer function. In your example, it could be something like this: struct variables_in_a_that_are_visible_in_d { int aa; }; void d_nested_in_a(struct variables_in_a_that_are_visible_in_d *ascope) { // Variable dd, no…

Right, you could do that, it was more a question about how the closures work.

Re: What makes Nim practical?

#86
post #57

Earlier quoted context omitted.

What about variables nested within these functions then? Is scope enforced? i.e. you can reach back to variable aa in function a() from nested d() but can't reach variable dd in d() from a()?

I have no idea how it actually works, but it would be easy enough to implement by having nested functions take a parameter that's a pointer to a structure containing the variables that are in scope in the outer function. In your example, it could be something like this: struct variables_in_a_that_are_visible_in_d { int aa; }; void d_nested_in_a(struct variables_in_a_that_are_visible_in_d *ascope) { // Variable dd, no…

  proc a =
    var x = 10
    proc b = echo x
    b()
  a()

Comes pretty close, the struct is further up: https://gist.github.com/def-/c496cd42774617fd0271#file-nestc...

Re: What makes Nim practical?

#87
post #5

I just realized something: Nim is like a faster Python or a better Go lang It's not really competing in quite the same space as say, D or Rust. It's like a statically typed scripting language.

There's 1 thing that can't be done in Nim that you can do in Go though. And that is the goroutine system. Something like that needs to be explicitly baked into the language. You can try to emulate it with your own thread pools but you will never get the same level of preemption.

However few people will ever need this feature, and erlang/elixir probably does it better, though at a the cost of speed.

Re: What makes Nim practical?

#88

I wonder if it can generate bindings for Python like Vala does[0]? That would make it even more interesting for Python developers. [0] https://github.com/antono/vala-object

I haven't looked closely at the Vala stuff that you mentioned, but it is very straightforward to generate shared libraries in Nim with exported functions that you can access via ctypes. That's not quite the same as generating a python module that you can directly import, but it gets the job done.

You might also be interested in NimBorg, https://github.com/micklat/NimBorg , which supports embedding Python or Lua in a Nim program.

Re: What makes Nim practical?

#89
post #15

I tried it and it is easy and fast. But the ecosystem is still not very large. I think that it should support building libriaries directly accessible from python including passing numpy arrays directly to nim. That would make a lot of people to jump right in creating libraries and thus extending its own ecosystem.

Something like Julia's PyCall package that allows calling arbitrary Python packages from Julia would also be great.

NimBorg is what you're looking for, https://github.com/micklat/NimBorg

Re: What makes Nim practical?

#90
post #48
post #21

Earlier quoted context omitted.

Nim isn't compiled to C in the same way that, say, Coffeescript is compiled to Javascript. Nim's compiler converts the AST into an intermediate representation that can be compiled to several backend. The primary backend is C source code, but it also supports outputting Javascript (experimentally) or interpreting the intermediate representation ala Python. The difficulty of developing the IR -> C transformation certai…

Your example isn't exactly true. Clang and GCC both do tail call optimizations. Compiling language functions to C functions doesn't 100% preclude you from TCO. http://david.wragg.org/blog/2014/02/c-tail-calls-1.html

It will, otherwise semantics will depend on which C compiler is available and ANSI C doesn't require TCO.
Post reply on HN