Hey Esa, Another great instructive email! Thanks again! I will keep this response short because I am sure you are busy and you have been more than helpful so far. I also need to get back to working through the code...
I hope my answer helps, but if it gets you more confused, maybe it's just because I'm confused...
No, you are just trying to understand what I am saying and since I am new to GHC's rts internals I do not yet have the knowledge to express my thoughts well.
There are other nicer things about that as well - untying Integer (atleast mostly) from runtime/frontend and moving it more into domain of libraries.
<snip>
Another program? I assume you meant outside pure haskell - "call- outs" have side-effects. We can get around by using unsafePerformIO, which doesn't really differ that much from writing it in C-- (and library in C), except we'd write haskell.
If the program (written in C--, C, C++, whatever) and the interface from Haskell to that program were well-typed it would not be any different than writing the entire program in Haskell, but the order of execution must remain in sync with the Haskell program. If the rts is threaded or parallel you might imagine problems cropping up. In this case I have to evaluate whether, say, OpenSSL's BN library is threaded (or, for Parallel Haskell, also working through PVM), not merely thread safe and certainly not merely reentrant.
Uhm, naturally, haskell rts needs to control lifetime of the memory. I am not sure what you're trying to say here, really. Is the point that we cannot free almost anything without permission from garbage collector? Because, yeah, we can't.
My problem was not with the garbage collector but with what the garbage collector depends on: when an object is evaluated and no longer in scope. I am not insane enough to attempt writing high level mathematical operations such as pow() or sqrt() as primitives in an integrated Bignum implementation, but you might be able to imagine that at that level it would be possible to choose when to save and when to evaluate parts of a long equation.
As I understand, you suggest here copying payload instead of merging memory handling. I don't think it's clearly, if ever, less efficient than ForeignPtr-based approach. But I'd guess it is *more* code than current solution.
Excellent point.
The third alternative I suggested previously was to embed the Bignum processing in GHC itself. I think it would be very difficult to maintain a solution that was both optimised and portable, at least in C--. (I may be way-off here; I am simply going by a rudimentary knowledge of BLAST implementations.)
I don't think it differs much from doing the same in C. It does seem shame to write bignum in C--, as we don't get many elegance-style advantages from writing it in C-- instead of C.
<cut and paste from below>
As for what it has to do with topic at hand, I have no idea. C-- is simply used as an intermediate language for the compiler, for convience of calling conventions and such, some low-level operations are written in it.
When I mentioned BLAS (not "BLAST", sorry) implementations I meant that--as I understand it--some may contain hand-optimised code written in assembler. Certainly I would personally prefer implementing something in C but as you noted C-- allows GHC more convenience. C-- may also allow GHC to manipulate fragments and produce native code in ways that may not be possible to express in C, including the Bignum implementation. I don't know whether GHC takes - fasm to this extent, that is, further than patching object code from a Bignum library, but that I think that is one of the long-term goals.
... One of the big ToDo's seems to be to correct the method of configuring this stuff using machdep.h or the equivalent on a local system, such as the sysctl-headers on Darwin. For C-- this seems like it would be a bit more difficult than simply confirming whether (or how) the C implementation conforms to the current standard through the usual header system.
Neither C or C-- was meant to be used to detect what system can do. It is simply a byproduct, which autotools takes to the extreme.
I meant that the autotools determine the correct configuration--the big ToDo--and that C or C-- code must be written to conform to the configuration that the autotools found. C would certainly be the easiest; C-- would mean reaching deep into the specs. C would also open the possibility for optimisations from compilers and system libraries that would not be available to C--. One more reason to use a separate Bignum library... Best regards, Peter