Hi Guys,
How are you? How is my favourite programming language? I really hope that Nim will take off and will have the popularity it truely deserves!
I haven't followed the recent development of Nim, so I came here to ask for a quick update. I brought a list of questions with myself (as usual if you remember me from before).
Feel free to say bad things about these questions (e.g., "we will never support this", or "%#@!@#??!"). I understand that it is not possible to make everyone happy.
Cheers, Peter
Q1: Is there any improvement of channels? Is is possible to listen to multiple channels at the same time from one thread (like with select in Go)?
Q2: Is it possible to share data with channels without having the channel in global memory? In other words, can I spin off a thread, create a channel on-the-fly, and use it to communicate with the newly created thread?
Q3: Is there any update on the compiler front? Are strings still copied when passed to a function inside a tuple: f((a: myString))?
Q4: Is there a progress in the escape analysis? If yes, is it helping closures not to copy all the references (can the closure iterator decide whether the referenced object is on the heap or stack)? Are the closure references read-only?
Q5: Any update on sequtils? Any new map/filter/reduce magic? New container types? An iterator library?
Q6: Any changes about the iterators? Are inline and closure iterators got any closer to each other? I remember I had to check both type(a()) and type(a.iter()) to be sure (however, don't ask for more details, it was a long time ago).
Q7: Is there any way to make a read-only promise on refs in a function declaration? My motivation for this is the compiler itself: it uses pointers of the nodes (which is fast), but it is hard to tell which of the parameters will be modified by the given function.
Q8: Are destructors working? I understand that any random data may look like a pointer to a class, therefore we cannot garantee to call every destructor at the right time. However, if destructors are called, we could free up memory, and destructors could be called when the program terminates to close file handlers/connections properly. (Don't ask me what to do if there is a circular reference when the program terminates.)
Q9: Any new helper functions to write macros? E.g., create a proc with the given parameters and the given generics (without the fear that AST's structure will change in the future).
Q10: Is there an immutable string? I remember a long discussion, and maybe the result was that both immutable and mutable can be extremely useful (e.g., there is no need to copy an immutable string when used as a key in a dictionary).
Q11: Is "concept" in a better shape when they are used with templates? Can I create a Map[T,S] concept (like in Java), with multiple different implementation (like HashMap, TreeMap)?
Q12: Is there a way to understand templates/macros better by looking the changes they make? For example is it possible to generate code from AST, or print AST and parse it back? My motivation is to see what happens when a template/macro has been evaluated (things can be complicated, e.g., macros can generate macros, injecting/binding variables, etc.).
Hello Peter !
Q5: the fastest functional style chaining library out there: https://github.com/alehander42/zero-functional (including bench vs C++, Rust, Haskell ...)
Q9: Declarative macro creation - https://github.com/alehander42/breeze
Q12: Have a look at dumpTree, treerepr, dumpASTGen and expandMacros
Q2: Yes, but only unsafely, because you have to use raw ptr to pass the channel (ref can't be passed between threads). Thus, it is possible, but the dangling reference or double free is on you :)
Random idea: use SharedTable to store the channels?
If you loop for checking the channels using tryRecv, it will be busy-waiting, but if you listen with recv , it will block the current thread.
If you can ensure the consumer thread is only one, you can add the additional condition to block the loop and only resume the loop checking when there's a message to one of channels.