I do think Nimrod will catch on in a little while. It has amazing potential. But things like type classes aren't done yet.
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.
At least in the devel branch type classes seem to be working:
type Comparable = generic x, y
(x < y) is bool
This creates a Comparable typeclass, which can then be instantiated:
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
And used elsewhere in generic code:
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)
Three reasons: dependent typing (limited support, but enough to represent statically sized vectors), powerful macro system (functions doesn't work to well as an abstraction in HDL.. this allows us to create new kinds of abstractions, like state-machines and pipelines), and generics/type classes.
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.
I worked on a HDL based in Haskell as an undergraduate project[1], and I'm about to start a PhD exploring the design of HDLs.
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.
I didn't realise Nimrod had this feature, so I might need to take another look at it.
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.
Comments
I do think Nimrod will catch on in a little while. It has amazing potential. But things like type classes aren't done yet.
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.
At least in the devel branch type classes seem to be working:
This creates a Comparable typeclass, which can then be instantiated: And used elsewhere in generic code:Could you elaborate on why you think it would be a good HDL?
Three reasons: dependent typing (limited support, but enough to represent statically sized vectors), powerful macro system (functions doesn't work to well as an abstraction in HDL.. this allows us to create new kinds of abstractions, like state-machines and pipelines), and generics/type classes.
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.
I worked on a HDL based in Haskell as an undergraduate project[1], and I'm about to start a PhD exploring the design of HDLs.
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.
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.
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.
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.
[1] https://github.com/aninhumer/mantle
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.
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.
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.