sonyandy

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.

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.

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.)

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).

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

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; }
  });

"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.

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.

Simple syntax is not the same as simple semantics.

An extension that GHC provides, and therefore part of the effective standard, is Safe Haskell (http://www.haskell.org/ghc/docs/7.4.2/html/users_guide/safe-...). A Safe (compiled with -XSafe, containing the LANGUAGE Safe pragma, or inferred) module may not define any manual instances of Typeable.