On a related note, the most principled approach to macros for an infix language I've yet seen is Honu (brought to you by the Racket people): http://www.cs.utah.edu/plt/publications/gpce12-rf.pdf .
Nimrod: A New Approach to Metaprogramming [video]
81–84 of 84 posts
Re: Nimrod: A New Approach to Metaprogramming [video]
#82Earlier quoted context omitted.
Nimrod's GC is not thread safe, last I checked. So if you aren't careful to avoid races on shared memory, you can segfault. Also, you incur full heap scans to clean up cycles.
Yes it is. Threads don't share a GC - there's no implicit sharedness. Memory is copied between threads. And of course, it doesn't prevent manual management of shared memory (just not GCd) so you CAN use locks to do so. Just like other languages. I turn off the cycle collector in my realtime apps. I prefer designing a clean, solid system that isn't reliant on cycles without my direct knowing. I guess that's just my in…
Re: Nimrod: A New Approach to Metaprogramming [video]
#83Earlier quoted context omitted.
Yes it is. Threads don't share a GC - there's no implicit sharedness. Memory is copied between threads. And of course, it doesn't prevent manual management of shared memory (just not GCd) so you CAN use locks to do so. Just like other languages. I turn off the cycle collector in my realtime apps. I prefer designing a clean, solid system that isn't reliant on cycles without my direct knowing. I guess that's just my in…
It's not just like other languages. Other languages don't segfault when you use shared memory.
Oh, and I said that it has locks like every other language. I didn't mean shared memory like every other language.
Finally - if you're just being smug at how smart rust is for having lifetime tracking and all those pointer types/restrictions - I don't think it's all that great; Nor did the gaming community when they got their hands on it last; Nor do many others who agree in the opinion that rust is just too complex while being too restricted.
Re: Nimrod: A New Approach to Metaprogramming [video]
#84Earlier quoted context omitted.
It's not just like other languages. Other languages don't segfault when you use shared memory.
What in the HELL are you talking about? The thread local GC won't even produce anything on the shared heap - it's thread local. Shared memory is manual memory only - Just like C, C++, Ada, and every other manual memory management language. And when the shared GC (which will have to be used explicitly) is implemented - it'll be just like Java, OCaml, and every other shared memory garbage collected language. What in Go…
Hybrid automatic and unsafe manual memory management (when the unsafe portion is for something really common like shared memory) is not something I'm really a fan of; it gives up safety while retaining the disadvantages of automatic memory management (lack of control, overhead). I think that safe automatic or fully manual schemes are the ones that have won out in practice because they get to fully exploit the advantages of their choices (safety in one case, control in the other).