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.