On Mon, Jul 15, 2013 at 11:25 AM, Sandro Magi <[email protected]>wrote:
> If you're willing to defer manual memory management for awhile, GHC core > [1] is a good target since it supports unboxed types [2], and you can > output the core [3] and inspect/debug it. With a suitable monadic > library [4], you can even add manual resource management, although I > suspect compiling large programs with a lot of resources will be quite > difficult. > Good thought for later. Trying to stay focused, so I'm not going to try to spin up on this at the moment. > I personally think C as a target is the only way to go if you're not > happy with LLVM. I'm actually pretty happy with LLVM at this point. My concerns for immediate purposes are: 1. I don't know the state of GC support, though I know it's improved. Your pointer to CHICKEN is helpful. In the long term this is a solvable problem. 2. Support for debugging late-generated code, since in later versions of BitC it became clear that dynamic compilation is a pragmatic requirement for generic libraries. In the long term, this is a solvable issue. 3. Short-term learning curve. So I think I'm down to LLVM and CIL. My intuition is to target CIL for the very short term. If nothing else, it's a target we want. Many people (including Sandro in his note) have said words to the effect of "oh, this is straightforward, you just do X or Y transformation." And they have been correct in every case. But straightforward things often take months to debug and implement in practice. For a long-term language building exercise, that may be fine. For a quick bring-up it isn't, and even for a long-term effort, there are major advantages for validating the language and starting to build libraries by having a quick bring-up path. Jonathan
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
