Hi Russel - On 10/16/15, 4:46 AM, "Russel Winder" <[email protected]> wrote:
>Hi, > >Is there an intention to move to using modern C++ for the Chapel >implementation, C++11 or C++14? The current C++ code I am looking at is >seeming very 1990s. > >Is there any intention to become a self-hosting compiler by rewriting >Chapel in Chapel? These are interesting questions. I'll give my answer, but others might want to elaborate further. First, about modern C++, the Chapel runtime is C (mostly) so that at least it's possible for target architectures that only support C to build and run Chapel programs. (In that case you would need to compile your Chapel programs on a system that had C++ support). I think we have some plans (but I'm not sure when) to moving to supporting C11 atomics and complex numbers in the runtime. I think that some of the C++11/C11 threading features will be useful to us in the runtime going forward. For the compiler itself, which is where most of our C++ code is, it's not so clear to me how C++11 helps us. Note that when building a Chapel compiler with LLVM support (for extern block support or for LLVM code generation), we already require C++11 because the LLVM project made it a requirement. In any case we don't make very heavy use of the C++ features that I view C++11 as improving the most. (as you said, very 1990s). * the compiler mostly uses its own strategy for memory management (sort of AST node garbage collection betwene passes), so things like unique_ptr/shared_ptr don't seem so important * we don't do much with templates or function objects. (At least not yet). So the C++11 lambdas don't really offer an immediate improvement. * the compiler itself is single-threaded, so C++11's much better support for multi-threading isn't immediately useful to us. I think that as we think about how to improve our compiler's architecture and AST representations, we will consider C++11. We could probably make use of auto declarations or the new hash table support. Regarding making a self-hosted compiler - I think making the compiler self-hosting is an interesting idea and is technically appealing to me. However, it pretty much means rewriting the compiler and I don't see how it would help Chapel users in the short term. Another detail is that as far as I know, to make a self-hosting compiler you need to keep around anon-self-hosting compiler/interpreter. Some projects just use an earlier version of the compiler and others have a compiler or interpreter for a reduced-functionality subset of the language. If there is any benefit to making a self-hosting Chapel compiler, I think it is in exercising more of the language. But that benefit is diminished if the compiler is not using the same subset of the language as everybody else... Cheers, -michael ------------------------------------------------------------------------------ _______________________________________________ Chapel-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-developers
