On Fri, 2015-10-16 at 11:39 +0000, Michael Ferguson wrote: > […] > > 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 have to admit it didn't strike me that there would a situation where there was a C compiler but no C++ compiler. In my old world of smartcards, processors were weird, there were special instructions, and C/assembly was the order of the day. I suspect with some effort C++ could be made to work but the compiler/IDE vendors didn't want to bother. In HPC and general computing though, I would have thought every processor had a C++ compiler. Sounds like I am wrong. > 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. I am finding asynchronous functions, futures, lambdas, and the coming ranges have made C++ such a different language. However D, Rust, Go and Chapel (and X10 :-) are far ahead in terms of modules etc. > 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 I guess I just get very itchy when I see bare pointers being used. I am a big "use RAII for memory management" fan for languages without a built in garbage collector. > * 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. Using the language of patterns: you must have Visitor, Command, Strategy patterns everywhere since almost every compiler is awash with them. Most of the complexity of these patterns as shown in GoF goes away with the use of higher-order functions. Which is why the patterns never appear in functional languages, and why there are so many talks now on "updated patterns for C++ and Java". > * the compiler itself is single-threaded, so C++11's much better > support > for multi-threading isn't immediately useful to us. Quite. :-) Is the compiler necessarily single threaded, i.e. it avoids lots of lock/mutexes. I guess AST build and traversal is the core issue here. > 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. It's not worth change just for the sake of using the features – though I would still be looking to get rid of bare pointers! > 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... Most reactions appear to have been, "why bother – Chapel is for numeric computation, and we already have the C++ code". For C++, Rust, Go, Java, etc. the single biggest argument in favour of self-hosting has been a marketing one, followed very quickly by programmers using the language can work on the compiler and runtime system as well. It's really the latter that drove me to mention it. However, it is a proof of concept thing as well. The language can do all the parsing, AST transformation and code generation. -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:[email protected] 41 Buckmaster Road m: +44 7770 465 077 xmpp: [email protected] London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------------
_______________________________________________ Chapel-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-developers
