That's the joke.

I'd be very interested in a low level FP without GC (including reference counting), as well. I believe a major difficulty is how do deal with closures. Obvious solutions include region inference and copying the closure, both with obvious downsides. Another difficultly is how to deal with structure sharing, a technique required for the efficiency of almost all functional data structures.

I have been thinking about this lately and found this last week http://www.ats-lang.org

It is in fact incorrect. The incorrect assumption is nested structure implies nested destructor calls. This can be avoided by ensuring each node in the structure does not destroy the next node_ptr (explicitly or more likely implicitly). Instead, the destruction has to happen more manually (internally to the overall data structure - not by the user). If the structure only recurses on one child, it can be performed as a loop.

Luckily, you can do the rewrite manually. I recently implemented an array mapped trie that shared structure when copied. `find`, `erase`, and `at` were all rewritten to use loops after first implementing them recursively (and profiling indicated it to be a problem).

If you follow the link, the issue isn't iteration, iteration is easy. The issue is the recursive destruction of the tree when the root is destroyed and no subtree is shared.

> The list implementation is simple/nice but it imposes a limit on number of stored elements because of "additional effect" of recursive destruction.

How would you perform destruction of a tree with more than one child tail recursively? I mean this as an honest question - my current implementation of array_mapped_trie performs this operation via non-tail recursive calls.

EDIT: I also don't see how destruction of a list is any harder than iteration of a list, as far as writing it tail recursively. You would need to make sure your node destructors are trivial, but you probably need to do this anyway if you intend to support using a custom Allocator (would instead have template <typename Allocator> destroy(node*, Allocator&); that calls Allocator::destroy on the contained value and Allocator::deallocate on the node). The implementation would then look something along the lines of:

decltype(head) next; for (auto ptr = head; ptr; ptr = next) { next = ptr->next; if (ptr->unique()) { destroy(ptr, allocator); } }

(unique() is a method on node - intrusive ref count.)

To "what's the point of immutable objects?": runtime polymorphism + maintaining invariants (since immutable, at the time of construction).

Why do you need objects to get runtime polymorphism?

Here's a counterexample of runtime polymorphism without objects: http://clojure.org/runtime_polymorphism

In addition to Compiling with Continuations, I found Compiling with Continuations, Continued by Andrew Kennedy very useful, as well.

http://research.microsoft.com/pubs/64044/compilingwithcontin...

What about

  function nothing() {
    return {
      match: function(cases) { return cases.nothing(); }
    };
  }

  function just(x) {
    return {
      match: function(cases) { return cases.just(x); }
    };
  }

  just(1).match({
    just: function(x) { return x + 1; }
    nothing: function() { return 0; }
  });

Right, but now you're not using null. The question was how to justify the use of sum types for null... not whether or not they could be emulated in some non-idiomatic manner.

"survival of the fittest" is closer to "not survival of the not fittest" than "not survival of the not-fit", which is not the same as "death to the weakest".

In C++, duck typing (structural typing) could be represented explicitly using type erasure (explicit in how you have to declare what the structure is) or using templates, which do not require declaration of the structure beyond the actual use in code (though concepts allow you provide structure requirements). Templates result in code being generated for each set of template arguments used. Type erasure does not - or at least not nearly as much (the constructors of the type-erased type almost certainly use templates). In this way, the type erasure approach most closely resembles the behavior of Python (virtual calls), while the template approach most closely resembles the style of Python (no declaration of structure required). There is no ideal way to get both the behavior and style of Python, but you can get pretty close by passing only one type of type-erased type to a function template - only one template function will be produced, which would make calls to virtual functions.

Amazing, advanced C++ is simply beautiful :P It is very interesting to learn about the hoops static type checking has to jump through.

Just because it's C doesn't mean it's the minimal library. Additionally, just because it's header-only C++ doesn't mean it's the minimal interface.