|
Stepanov (i.e., Mr. C++ Standard Template Library) has said some comparably strong things about the expressiveness of C++ templates for the kinds of things expressed in STL, and he doesn't seem to be guilty of not investigating Lispy alternatives. e.g., http://www.antiquark.com/escape/public_html/stepanovusa.html There are various gnarly problems with C++'s model, some of which show up as gnarly problems in STL, even in fundamental stuff like implementing collections of refcounting pointers last time I looked. But as far as I can tell, every language which tries to get this correct within the language has some serious limitations or issues, arguably at least as bad, especially if like Stepanov one of your top priorities is eliminating every last bit of runtime overhead in the generated code. (E.g., implementing arrays of objects only as arrays of fixed-size pointers into variable-sized objects on the heap, as in typical CL and Java, is a no-go given STL priorities, and thus STL constantly wrestles with a bunch of problems that lots of other implementors have dodged by giving up on them.) As far as I know, no one has a comprehensively satisfactory solution for metalanguage facilities within the language. Getting metalanguage correct by stepping outside the language and upstream from the compiler, writing a separate program to generate the target program, has been a solved problem as long as we've known how to write compilers in Turing-complete languages. That approach is sometimes used for app code in conventional languages, as in FFTW, and to some extent it's what Lispy macros do. But for some applications, including STL as I understand it, stepping upstream is unsatisfactory. Sometimes what you'd really like to do is have your code generator query the compiler about what the compiler knows. STL in particular, IIRC, wants to have its code generation depend on what the compiler knows about types and typedefs and so forth. In an ideal world it would be routine for code generators to be able to ask the compiler about other things, too, like dead code, namespaces, and safety and other pragmas. |