Re: [Boost-users] [fusion] sequence conversion

From: Zeljko Vrba (zvrba_at_[hidden])
Date: 2008-07-20 04:20:08

On Sun, Jul 20, 2008 at 08:14:16AM +0800, Joel de Guzman wrote:
> 
> Look at it this way: Imagine a world where STL didn't have iterators
> and algorithms.
> 
These are tools to get the job done.  I can map my problem domain to these
tools well, which is not the case with fusion.  (As I said earlier -- I do
*not* claim that fusion is useless -- just that I might be working in a wrong
problem domain, and that's what I'm trying to find out.)

> 
> STL is still immensely useful. It does not have a pattern-matching facility.
> MPL is still immensely useful. It does not have a pattern-matching facility.
>
Neither claims to implement tuples.

Ironically enough, I *do* see how zip/filter/etc. are useful -- I used them
extensively when coding in ML.  However, in ML they work on lists of arbitrary
length, not on tuples of fixed length, and this generality, together with low
barrier of entry (friendly syntax, mostly informative error messages), makes
functional style of thinking easy and encourages it.  These algorithms just "do
not seem" useful at compile-time..  at least not when I'm thinking ML where
probably most of the features provided by fusion come "for free", as
nonintrusive, almost invisible, language features.

I guess my expectations of fusion are too high -- not only it heavily uses
templates, which I personally consider as very user-unfriendly feature of C++
(syntax, huge and obscure error messages = high barrier to entry even for
experimentation), but it also comes so close, but still a bit short of ML's
functionality (and comfort).

>
> I think you are searching the wrong problem domain.
> 
Probably yes.  Most examples that have emerged so far come from constructing
generic libraries.  A question from another, "traditional" perspective: can
some of fusion's facilities, beyond simple tuples, be useful even if one does
not need any variability of data structures and algorithms at compile-time?
If so, an example would be nice.

Or to reformulate the question again: it would be nice to have examples of
using fusion to solve "concrete problems", where data structures may have been
already decided, rather than to design interfaces ("abstract problems").

The CSV parser already mentioned is a nice example "in-between" the two
extremes -- the "abstract problem" is small (just the decision to use fusion
for representing the CSV row), and the rest (filtering, transformations, etc.)
are concrete tasks.  Or the SQL library example.  I would welcome more such
examples: little abstraction (re. data structures), a lot of functionality
gained.

> 
> Introspection, for one. Can you iterate over the types and data of
> an arbitrary struct? No.
>
No.  But why would I want to?  struct is a container for stuff, designed by me
for a specific purpose, used by me for that specific purpose, and I *know* what
stuff is in the structure and for what purpose it is used for.

Arbitrary struct?  What is the use of iterating over elements of an *arbitrary*
struct if one does not have any semantic knowledge about the contents?  OK,
serialization might be one limited[1] use-case.  More examples? 

[1] Limited because not even serialization is possible in all cases without
semantic knowledge about the contents.

>
> Genericity, for another. I can write a
> generic function (algorithm) that works on *all* fusion maps,
> more significantly -all fusion sequences.
> 
Great!  What useful could that function do, at run-time?  Serialization, as we
agreed, is one use case, and also the one shown in the quick start chapter of
the manual.  What more interesting can you do *at run-time* without semantic
knowledge about the contents? 

> 
> YMMV. You can even code in assembler, if you like. It's the abstraction!
> 
The best programmers code in Fortran.

Yes, it's the abstraction -- of WHAT?  Abstractions for the sake of themselves
are of limited usefulness... even in mathematics, abstractions are created to
ease study of certain topics, i.e., they always have (one or more) underlying
concrete models, which might again be built on other abstractions, but which
give semantics to the abstraction.

What is (one of) the underlying semantics that fusion's iterators, algorithms,
etc. emerged from?  Model and semantics, in this case, would be a concrete
runtime problem that needed to be solved.