On 24/12/2010 18:14, Thomas Heller wrote:

(My apologies for the delay in responding; I've been travelling for the holidays and had irregular access to email.)

I think this comprehension syntax would be a wonderful addition to phoenix. In fact i was thinking of adding it to phoenix V3 myself. By basing your work on phoenix v3 you would introduce a kind of big dependency, true. However, that dependency is imho not a bad thing, it would provide you with a powerful basis for your work. The only thing that needed to be done is to code the logic for the list comprehension... everything else is already done for you.

I managed to make a little time to acquaint myself with Phoenix (v2) and discovered that it wasn't that hard to add Phoenix support to the comprehension library-- a couple of traits specializations to derive the return types, a special case to treat void values as 'true' for the purpose of continuing the comprehension (applies in all cases, not just when using Phoenix expressions), and a mechanism to limit ambiguous operator overloads. I just uploaded a new version of the comprehension library (0.02) to the Vault that includes all of the above, along with the ability to nest comprehensions, support for increment/decrement and assignment operators, general code cleanup, a couple of compiler workarounds, reorganized example programs, and most importantly some preliminary documentation in the README file. As always, I'd appreciate reports of any compilation environments or use cases that cause problems. As far as integrating the comprehension syntax directly into Phoenix goes, it certainly looks feasible but I wonder how much there really is to be gained. Since Phoenix already overloads the <<= (and every other) operator, you'd either have to introduce a wordier sequential-assignment syntax or a special sequentially-assignable type, in which case the comprehension engine might as well be a separate component. One thing that would be handy in v3, though, would be control flow operators that return a value type (e.g. the value of the last expression in the statement list) rather than void. Right now if you need a comprehension to depend on some value computed within the body of a complex Phoenix statement, you have to assign that value to a temporary variable and reference the variable later in the comprehension. I think that this capability would be more generally useful outside the comprehension context, and it would mirror the semantics of many functional languages. I'm still not familiar enough with the Phoenix internals to recognize whether there's some other constraint that makes this impractical. On a more technical note, does anyone know of a safe compile-time way to detect whether the -std=c++0x (or /Qstd=c++0x) command-line option has been passed to the Intel C++ compiler? http://stackoverflow.com/questions/3744023/detecting-c0x-mode-on-intel-c suggests that the the constant __GXX_EXPERIMENTAL_CXX0X__ will be defined (as it is in g++), but that doesn't seem to be true, at least in version 12 under Linux. boost/config/compiler/intel.hpp doesn't seem to have any tricks for this either, which is unfortunate because it never enables BOOST_HAS_DECLTYPE, and the compiler chokes on parts of Boost.Typeof when -std=c++0x is /not/ defined (i.e. when you actually need it most.) Brent