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.