Add support for Char literals in Program and support for 64 bit numtypes to external program.

[emwap]

What is the use-case for char? Is it not enough with uint8_t?

[pjonsson]

We need string constants for faithfully representing the current implementation of pow_fun_intN_t() in Program. We could probably get away with representing strings as array literals of uint8_t and do some clever interpretation of things, but that will touch code paths in the compiler that matter for the important signal processing computations.

[emwap]

Is that for the error message? Then, why not use Assert from Feldspar.Core.Constructs.Error?

[pjonsson]

We could use that but it's not what the current implementation does. I'm not sure I have a strong opinion on whether assert would suffice. What assert doesn't suffice for is the implementation of the trace functions since they need string constants for the non-exceptional case.

[emwap]

I think assert would be ok for this case. However, I'm not sure we should have the runtime check anyway. Can you add an assert for now and then we can try to impose static checks instead.

I think we should remove the trace functions for now, since their implementation is lacking in performance and they are not widely used.

[pjonsson]

I'm happy to change the semantics so reverted the Char commit.

I'm not sure how much checking we need to be honest. overflows might be a real problem but the assert is in a place where there's a sign that something overflowed before we got to that point. The assert should be in the place where we were overflowing instead.

[pjonsson]

Pull request #163 removes the support for Trace.