Nimrod by Example
nimrod-by-example.github.io
nimrod-by-example.github.io
For instance, I just need to add two lines to import C's printf and fprintf:
proc printf(frmt: CString) {.importc: "printf", nodecl, varargs, tags: [FWriteIO].}
proc fprintf(f: TFile, frmt: CString) {.importc: "fprintf", nodecl, varargs, tags: [FWriteIO].}
Now I can use these C functions seamlessly (even without parentheses):
printf "Hello %s!\n", "world"
fprintf stderr, "Error in line %d\n", $nr
from ctypes import *
libc = CDLL("libc.so.6")
libc.printf("Hello %s!\n", "world")
from sys import stderr
libc.fprintf(stderr.fileno(), "Error in line %d\n", nr)
I spent a few days solving Rosetta Code tasks and was surprised how easy most were using the existing libraries: http://rosettacode.org/wiki/Category:Nimrod
1) Huge institutional support. See: C#, Java, Go.
2) Give it 20 years. See: Python, Haskell.
3) Weird, idiosyncratic factors. See: Javascript, mostly.
So it's hard for me to get excited about these sorts of things.
Edit: fair point, Javascript is really a case of #1, with Netscape as the institution.
Writing traditional compilers and interpreters, or emitting C, or targeting LLVM have all proven to be good ways of getting production-grade programming language implementations created and usable quickly. Messing around with Parrot has never resulted in anything useful.
pg said that for a language to become popular, it has to be the scripting language of something popular. That's the category where the three languages I mentioned are falling.
So the answer is simple: one has to build something really nice in Nimrod and use Nimrod as the extension language of that thing. Maybe the embedded world would be a nice field from Nimrod due to having nice interop with C? (I haven't used Nimrod in my life yet, although I am tempted because it looks very easy).
Ruby I guess is a (3): Rails is a killer app.
C, well, it's the a major accomplishment of human civilization and has held up for half a century. I'd call that idiosyncratic.
As UNIX spread into the industry, so did C.
All languages required by OS vendors as the official ones to target their OS, succeed in the market if the OS succeeds.
The small ecosystem is definitely a concern, but could also be an opportunity for a mid-sized IT corp to step into the ring with the big hitters and all their shiny new systems languages by backing this project.
Personally I believe Nimrod will be perfect as a Hardware Description Language. There's a couple of features missing, but they're currently being worked on. This is an area where Nimrod could really shine, and where it could start to gain massive commercial support.
type Comparable = generic x, y
(x < y) is bool
type Foo = tuple[a, b: int]
proc `<`(x, y: Foo): bool =
if x.a < y.a: true
elif x.a > y.a: false
else: x.b < y.b
var c: Foo = (12, 13)
var d: Foo = (14, 15)
echo c < d # true
proc min[T: Comparable](xs: openarray[T]): T =
assert xs.len > 0
result = xs[0]
for x in xs:
if x < result:
result = x
echo min([c,d]) # (a: 12, b: 13)The only other language I know that has similar amount of power is Idris(but in a very different way). But Nimrod has another advantage: friendly syntax and semantics. HDL programmers are not generally good at programming, so I don't think Haskell or Idri based languages will catch on.
>dependent typing
I definitely agree with this. When you're writing a program to generate code, the distinction between compile time and runtime is essentially meaningless, so the boundary between types and values in Haskell ends up being a huge hassle for no good reason. It's also hard to explain the difference between numeric values and numeric types, when there doesn't need to be one in the first place.
I didn't realise Nimrod had this feature, so I might need to take another look at it.
>functions doesn't work to well as an abstraction in HDL
I'm not sure why you'd say that? Functions work great for abstracting chunks of combinational logic. Arguably one would prefer a more constrained abstraction though.
> friendly syntax and semantics ... I don't think Haskell or Idri based languages will catch on.
Bluespec took the approach of modifying Haskell syntax to look like Verilog. It's mostly quite effective, but I think they went slightly too far in throwing out some useful syntax features. Most notably, there are no lambda expressions in Bluespec, even though it could support them trivially.
>HDL programmers are not generally good at programming
I think this is a chicken and egg problem. HDLs suck, so there's not really any good practice to learn. Also competent programmers who can see the deficiencies tend to avoid the field.
I'm working with Bluespec in a team of mixed EE and CS backgrounds, and the EEs are learning much better programming practices as a result.
Yeah, it has it to a certain extent. But it's a minefield at the moment, and will never be as good as Idris for instance. But I'm sure it will good enough for bit vectors.
> I'm not sure why you'd say that? ...
You're right, I was thinking procedures, but wrote functions. A pure function is of course an excellent abstraction of combinatorial logic. A procedure could potential abstract sequential logic as well, with some restrictions/modifications.. but you really want other abstractions.
> Bluespec took the approach of modifying Haskell syntax to look like Verilog.
I'm very suspicious of this approach. If you expect Verilog but get something quite different, it could cause frustration. But I haven't tried Bluespec, so I shouldn't criticize too much. I suppose it's the only way they had a hope of getting more adoption.
I think that I could use the 'importc'/'dynlib' with the compiled library, but there's not a whole lot of documentation on that in the Nimrod manual, and I ended up just doing that problem in C because it was easier (read: I was lazier) to get working.
http://rosettacode.org/wiki/Call_a_foreign-language_function...
http://rosettacode.org/wiki/Call_a_function_in_a_shared_libr...
http://rosettacode.org/wiki/Use_another_language_to_call_a_f...
Making c2nim work with header files can be a bit difficult. The main information is here: http://nimrod-lang.org/c2nim.html
When something throws an error I comment it out and try to see if I can fix it up by hand.
Importing a standard procedure from a C library like GMP actually is pretty easy (use the importc/header pragmas).
Here's what tripped me up:
* Calling variadic functions from Nimrod (just wrote a wrapper)
* Getting to link against gmp (used the passL: "-lgmp" pragma)
* Remembering to free what was allocated by C library functions (can't GC what you didn't allocate) - caught with valgrind
I'll probably push to my github repo, but can post to a pastebin or something if there's interest in a less cookie-cutter example
Either make it fully manual, or do something like Rust (No small feat). A GC you can switch on and off sounds like a good idea, but programmers don't keep half the promises they make ("It's just an MVP, I'll refactor it to use manual memory later").
And what would be the problem with that? The number of application domains where even soft real-time GC is inappropriate is very, very small. And designing freedom from garbage collection into a language (other than the simple option of allowing manual allocation/deallocation) is not cost-free, either, and can weigh down the design, too. You can optimize your language design for having garbage collection or for not having garbage collection, but if you try to do both at once, a language design that specifically favors one or the other will likely beat out the compromise solution for the case it's optimized for.
And yes, that means that Nimrod (or any other language) won't be perfect for everything under the sun. Which is fine: there's nothing wrong with having multiple programming languages, each of which is better suited for a different task.
What I hope will happen is that once Nimrod's effects system matures, the compiler will be able to figure out when it can statically free references when they go out of scope, rather than always using the GC.
Rusts approach, I think, is in the entirely wrong direction. You should only have one kind of reference, but if you use it correctly the compiler should figure out how to free it. You should then be able to make an assertion that a procedure (possibly "main") does not allocate any GC memory, and have the compiler tell you what part of your code violates this constraint.
"If you use it correctly the compiler will figure out how to free it" is extremely handwavy. If you try to formalize exactly what "use it correctly" means, you will likely arrive at something very similar to Rust's system.
To me this seems different enough to Rust's system, and while this won't be 100%, I think this will greatly reduce escape analysis failures, and especially this will eradicate escape analysis failures due to missed inlining. Whether it will be enough seems an open question to me (that is, to me, it doesn't seem destined to fail) and worth pursuing.
This has been an area of intense research for four or five decades now, and it's probably not going to get better than what we have now, in the general case. In the presence of general recursive data structures, the compiler can't know when each object is going to die. I'm pretty sure you can easily reduce this to the halting problem.
To date, you've had three sorts of solutions: 1) explicit malloc/free; 2) tracing GC or reference counting + various tricks to take advantage of special cases; and 3) putting additional information in the type system to help the compiler infer when objects might become free while preserving memory safety (this is the direction taken by Rust, Cyclone, MLKit, and to an extent C++ too).
For most code I personally know, that does not play well with GC (firmware, hard real-time, etc.), you really don't want to do much allocation after initialization anyway, and the little you do can be handled by malloc/free style manual memory management, or perhaps by escape analysis. And then I think Nimrods approach might work well, because you could declare that everything done by a proc should be verified by escape analysis, rather than manually tagging each pointer used in that procedure.
But I recognize that Rusts approach should be extremely useful in a few applications. But then again I wonder if Nimrods type-system eventually will be able to implement its most useful pointer types in a library.
Pretty much. I'd also add ParaSail to the list of languages that give the compiler more information (or more precisely, restricts what is possible, and for reasons other than just memory management).
I think it is valuable to research what is the best set of restrictions to get reliable escape analysis. For reliable escape analysis for unrestricted case, yes, I think it won't be possible and it isn't worth bothering with at all.
gcDisable()
while true:
gameLogic()
renderFrame()
gcStep(us = leftTime)
sleep(restTime)
I haven't looked at Nimrod's GC, but I believe it's indeed incremental; it won't take more time than you give it, but it will leave things uncollected if you don't give it [enough] time.
Also the GC is only triggered on a memory allocation. It doesn't run in a background thread or anything like that. So if the GC fails, then the allocation of memory fails (as I understand it) which means your scenario would be caught early.
Does this mean that they use different heaps?
You may also be interested in the C#-like async await as shown in the following news article: http://nimrod-lang.org/news.html#Z2014-04-21-version-0-9-4-r...