Re: [boost] An alternative approach to TypeErasure

Subject: Re: [boost] An alternative approach to TypeErasure
From: Pyry Jahkola (pyry.jahkola_at_[hidden])
Date: 2012-06-24 18:43:27

On 2012-06-24 15:13:28 +0000, Dave Abrahams said:

> After a quick skim: Very cool!

Kiitos!

> Reminds me a bit of something I did, entirely in the static
> polymorphism space:
> http://article.gmane.org/gmane.comp.lib.boost.devel/120408... But I
> guess your work is fundamentally different from what I was doing.

Interesting. Segmented ranges actually was one potential use case I was 
thinking when implementing poly::interface. Btw, has there been any 
work on the front of segmented ranges since in Boost? Or are we just 
waiting for Boost.SIMD currently?

> One thing I didn't see you mention there is that since your generic
> functions are first-class objects, they can be passed and returned,
> thereby supporting higher-order functional programming.

Good point! I definitely need to add that note to my README.

>> PS. Like I mention in my GitHub page, this kind of type erasure is
>> common in functional languages like Haskell or Clojure. The problem
>> they are solving there is known as the Expression Problem.
> 
> Is that different in essence from the Binary Method Problem?

No, it's about (I'm paraphrasing somewhat) being able to both

    (1) "easily" make more types implement an interface, and
    (2) "easily" add more functions to an interface.

Easily in (1) would mean, "without having to modify and recompile the 
whole interface (meaning the existing function implementations)". In 
(2), "without having to modify (and recompile) all the classes". If I'm 
not missing a point, both of these are relatively easy with my library, 
especially where templates can be used in defining the callable 
functions.

The Binary Method Problem seems to be about what I criticized in the 
operator overloading discussion of this thread an hour ago. What I'm 
saying is, I don't think the Binary Method Problem is the right problem 
to solve with type erasure, but I'm happy to hear any counter-arguments!

>> IMO it makes very much sense to have the corresponding construct in
>> C++ too, as we're moving towards a more and more functional style with
>> parallelism and such.
> 
> Well, it's not as though we can't already do functional programming in
> C++... I think you might be conflating issues here.  Isn't this really
> about a way to do runtime polymorphism with value semantics?

Hmm, you are be right that I went too far in saying that. But one nice 
property in both mine and (if I've understood correctly) Steven's 
libraries is that the functions remain external to the data structures, 
and can be easily composed (with higher order functions).

Obviously we all have been able to do FP in C++ for years without these 
new constructs.

-- 
Pyry Jahkola
pyry.jahkola_at_[hidden]
https://twitter.com/pyrtsa