4 ms·

The style of code in this presentation will also result in insane build times. I can't see FP taking off in C++ until it gets proper modules support; until then

by juunpp 3y ago

The style of code in this presentation will also result in insane build times. I can't see FP taking off in C++ until it gets proper modules support; until then, it's cursed by the O(N*M) nature of header compilation. And most of the projects I have worked on discourage or prohibit Boost, the STL, and heavy use of template code, for this and other reasons. I think there's a large disconnect by the kind of code in these presentations and what people in the industry actually use. I think wrapping stuff in std::function may also prevent inlining? I'm not sure how much link-time optimizations can help with that, but I'd guess languages like Haskell do better in this area. Also, C++ doesn't even have a function composition operator :/ The presentation starts off with "function application is the essence of FP", but it's really function composition. By his definition, C is a hell of an FP language.

dataflow 3y ago
> I can't see FP taking off in C++ until it gets proper modules support Modules aren't going to help with template instantiations.
- ender341341 3y ago
  they can, because now instead of having to re-instantiate std::vector<int> in every compilation unit it can just add it to the module's compiled unit and pull it in from there. Basically finally delivering on the promise of `export template foo<bar>` that never materialized after c++98
  - dataflow 3y ago
    Not sure I understand you correctly, but if I do, that has nothing to do with modules. If you already know what your template will be instantiated with (which is rare and hardly going to make a dent here), you can already just do extern template ... in a .h file you #include, and then explicitly instantiate it in some .cpp file. The problem (particularly for "functional programming" purposes) is that you don't generally have the template arguments available in advance; they're different for each client. See for example all the lambdas passed to algorithms like std::find_if(). So this isn't going to get you anywhere, practically speaking.
    - ender341341 3y ago
      extern template was removed from the standard cause it wasn't implemented by any of the common compilers so you can't use it (unless you use Comeau which appears to be abandoned). What it has to do with modules is you can effectively treat the module as a mini 'shared library' and when a template is instantiated you can append the compiled code into the module and re-use it in other compilation units.
      - dataflow 3y ago
        No, you're mixing up export and extern.
        ender341341 3y ago
        ahh, your right, I do think with the rest of my comment it basically allows automating `extern template` though.
        dataflow 3y ago
        You can't "append compiled code into a module" when templates can completely change the code that would've been compiled. This is C++, not Java. The only step that gets sped up for templates is their rudimentary parsing, which you trade off for the addition I/O of writing/reading the intermediate files in memory. Whether that small portion comes out ahead or not, it's dwarfed by the template instantiations the caller needs to do, which basically need to create the specialized AST nodes from scratch.
        ender341341 3y ago
        > You can't "append compiled code into a module" when templates can completely change the code that would've been compiled. Why can't you, I don't believe the standard says anything about the intermediary compiled unit of the module that would block it from doing so, I haven't dug into the implementations but I'd imagine they effectively create a static library analog of the compiled code and some analog of a header file for use in other compilation units, so say you're wanting to use std::vector<int> it can just look and see if that's already present in the module, if not instantiate it and then write it to the 'static library analog'
- pjmlp 3y ago
  They do in regards to parsing, semantic analysis, and keeping external templates around for common instations.
  - dataflow 3y ago
    Those don't make much of a dent when the vast majority of the problem lies elsewhere. See my reply to the sibling comment.
    - juunpp 3y ago
      This reminds me that the way Haskell/ghc implements/ed type classes, if I remember correctly, is not by instantiating them, but with a dictionary lookup[1], compiler tricks aside. I think that largely throws away the overhead of compiling template code... at the cost of the runtime overhead that C++ typically dislikes. [1] https://stackoverflow.com/questions/12645254/ghc-code-generation-for-type-class-function-calls https://stackoverflow.com/questions/12645254/ghc-code-genera...

by juunpp 3y ago

dataflow 3y ago

> I can't see FP taking off in C++ until it gets proper modules support Modules aren't going to help with template instantiations.

ender341341 3y ago
they can, because now instead of having to re-instantiate std::vector<int> in every compilation unit it can just add it to the module's compiled unit and pull it in from there. Basically finally delivering on the promise of `export template foo<bar>` that never materialized after c++98
- dataflow 3y ago
  Not sure I understand you correctly, but if I do, that has nothing to do with modules. If you already know what your template will be instantiated with (which is rare and hardly going to make a dent here), you can already just do extern template ... in a .h file you #include, and then explicitly instantiate it in some .cpp file. The problem (particularly for "functional programming" purposes) is that you don't generally have the template arguments available in advance; they're different for each client. See for example all the lambdas passed to algorithms like std::find_if(). So this isn't going to get you anywhere, practically speaking.
  - ender341341 3y ago
    extern template was removed from the standard cause it wasn't implemented by any of the common compilers so you can't use it (unless you use Comeau which appears to be abandoned). What it has to do with modules is you can effectively treat the module as a mini 'shared library' and when a template is instantiated you can append the compiled code into the module and re-use it in other compilation units.
    - dataflow 3y ago
      No, you're mixing up export and extern.
      - ender341341 3y ago
        ahh, your right, I do think with the rest of my comment it basically allows automating `extern template` though.
        dataflow 3y ago
        You can't "append compiled code into a module" when templates can completely change the code that would've been compiled. This is C++, not Java. The only step that gets sped up for templates is their rudimentary parsing, which you trade off for the addition I/O of writing/reading the intermediate files in memory. Whether that small portion comes out ahead or not, it's dwarfed by the template instantiations the caller needs to do, which basically need to create the specialized AST nodes from scratch.
        ender341341 3y ago
        > You can't "append compiled code into a module" when templates can completely change the code that would've been compiled. Why can't you, I don't believe the standard says anything about the intermediary compiled unit of the module that would block it from doing so, I haven't dug into the implementations but I'd imagine they effectively create a static library analog of the compiled code and some analog of a header file for use in other compilation units, so say you're wanting to use std::vector<int> it can just look and see if that's already present in the module, if not instantiate it and then write it to the 'static library analog'
pjmlp 3y ago
They do in regards to parsing, semantic analysis, and keeping external templates around for common instations.
- dataflow 3y ago
  Those don't make much of a dent when the vast majority of the problem lies elsewhere. See my reply to the sibling comment.
  - juunpp 3y ago
    This reminds me that the way Haskell/ghc implements/ed type classes, if I remember correctly, is not by instantiating them, but with a dictionary lookup[1], compiler tricks aside. I think that largely throws away the overhead of compiling template code... at the cost of the runtime overhead that C++ typically dislikes. [1] https://stackoverflow.com/questions/12645254/ghc-code-generation-for-type-class-function-calls https://stackoverflow.com/questions/12645254/ghc-code-genera...