[bind] list[01] -> fusion::tuple
Hi, I've attached a diff against HEAD for converting list0 and list1 in the bind implementation to using fusion::tuple (instead of storageN) as was recently suggested in the users mailing list by Peter Dimov. The main reason for doing this was to allow easy iteration over the list element types so that things like minimum arity for a bind expression can be computed. The solution I suggested was pretty hacky to say the least but it worked ;-). Anyway it should be pretty easy to do (if not just tedious). The tests compile and pass here for these changes (g++-4.1). Do the changes look sensible? The only sticking point seems to be the accept/visitor thing that appears to be unused except for in boost signals. Should this also be carried over? I can complete a patch and submit a track item in the next couple of days. Thanks, Sohai PS: I've also done the same change with phoenix::tuple so whichever one is preferred
Sohail Somani wrote:
Hi,
I've attached a diff against HEAD for converting list0 and list1 in the bind implementation to using fusion::tuple (instead of storageN) as was recently suggested in the users mailing list by Peter Dimov. The main reason for doing this was to allow easy iteration over the list element types so that things like minimum arity for a bind expression can be computed. The solution I suggested was pretty hacky to say the least but it worked ;-).
Anyway it should be pretty easy to do (if not just tedious). The tests compile and pass here for these changes (g++-4.1). Do the changes look sensible? The only sticking point seems to be the accept/visitor thing that appears to be unused except for in boost signals. Should this also be carried over? I can complete a patch and submit a track item in the next couple of days.
I need to warn you that there is very little chance for your patch to be accepted in this form. Extending _bi::listN (I'd suggest making them conforming MPL or fusion sequences) needs to be done non-intrusively and in a separate header.
-----Original Message----- From: boost-bounces@lists.boost.org on behalf of Peter Dimov I need to warn you that there is very little chance for your patch to be accepted in this form. Extending _bi::listN (I'd suggest making them conforming MPL or fusion sequences) needs to be done non-intrusively and in a separate header. ----- I understand what you mean here but didn't you say that the whole thing would be easier if one was to use a fusion tuple as L? I assumed that would have been the acceptable solution since you suggested that yourself. I would expect that making bind switch to tuple would be less work and more beneficial than introducing another sequence type (which I think is a lot more testing). FWIW, I'd be less interested in adding a new sequence type. Thanks for your reply. Sohail
Sohail Somani wrote:
-----Original Message----- From: boost-bounces@lists.boost.org on behalf of Peter Dimov
I need to warn you that there is very little chance for your patch to be accepted in this form. Extending _bi::listN (I'd suggest making them conforming MPL or fusion sequences) needs to be done non-intrusively and in a separate header.
-----
I understand what you mean here but didn't you say that the whole thing would be easier if one was to use a fusion tuple as L? I assumed that would have been the acceptable solution since you suggested that yourself. I would expect that making bind switch to tuple would be less work and more beneficial than introducing another sequence type (which I think is a lot more testing). FWIW, I'd be less interested in adding a new sequence type.
I understand Peter. It can be done non-intrusively. Fusion(2) was designed with a requirement that you should be able to "adapt" any type of tuple or tuple-like (even plain structs) sequences. I did that with boost.tuple, for example. One reason is backward compatibility. Boost.tuple already has a tremendous user base. I do not want to cause disruption by replacing Boost.tuple with fusion's native sequences. That would case disruption in many ways. So would replacing boost.bind's tuples. Adaptation is the way to go. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
-----Original Message----- From: boost-bounces@lists.boost.org on behalf of Joel de Guzman Sohail Somani wrote:
-----Original Message----- From: boost-bounces@lists.boost.org on behalf of Peter Dimov
I need to warn you that there is very little chance for your patch to be accepted in this form. Extending _bi::listN (I'd suggest making them conforming MPL or fusion sequences) needs to be done non-intrusively and in a separate header.
-----
I understand what you mean here but didn't you say that the whole thing would be easier if one was to use a fusion tuple as L?
I understand Peter. It can be done non-intrusively. Fusion(2) was designed with a requirement that you should be able to "adapt" ----- Yep, I'm with you both now. Thank you both very much! Good thing I posted before I spent too much time on it :) Sohail
-----Original Message----- From: boost-bounces@lists.boost.org on behalf of Peter Dimov I need to warn you that there is very little chance for your patch to be accepted in this form. Extending _bi::listN (I'd suggest making them conforming MPL or fusion sequences) needs to be done non-intrusively and in a separate header. ------ Hey Peter, I'm almost there doing it this way, but I gotta tell you that it requires generating code (attached) as you need lots of partial specializations. The reason is that there isn't one type but N types. Consider getting the type of the element at index I. Of course, even with changing to some other tuple as the underlying, I think you'd have to generate code (who would want to write it out by hand?!). Does that sound sensible or totally wrong? Sohail PS: It is pretty easy to extend fusion, I must say!
Sohail Somani wrote:
-----Original Message----- From: boost-bounces@lists.boost.org on behalf of Peter Dimov
I need to warn you that there is very little chance for your patch to be accepted in this form. Extending _bi::listN (I'd suggest making them conforming MPL or fusion sequences) needs to be done non-intrusively and in a separate header.
------
Hey Peter, I'm almost there doing it this way, but I gotta tell you that it requires generating code (attached) as you need lots of partial specializations. The reason is that there isn't one type but N types. Consider getting the type of the element at index I. Of course, even with changing to some other tuple as the underlying, I think you'd have to generate code (who would want to write it out by hand?!).
Does that sound sensible or totally wrong?
Sohail
PS: It is pretty easy to extend fusion, I must say!
------------------------------------------------------------------------
<snip the code>
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I think is an example of a case where the variaidic templates work done by Doug Gregor is a help in enabling a general implementation to be much shorter. John Fletcher
Sohail Somani wrote:
Hi,
I've attached a diff against HEAD for converting list0 and list1 in the bind implementation to using fusion::tuple (instead of storageN) as was recently suggested in the users mailing list by Peter Dimov. The main reason for doing this was to allow easy iteration over the list element types so that things like minimum arity for a bind expression can be computed. The solution I suggested was pretty hacky to say the least but it worked ;-).
Anyway it should be pretty easy to do (if not just tedious). The tests compile and pass here for these changes (g++-4.1). Do the changes look sensible? The only sticking point seems to be the accept/visitor thing that appears to be unused except for in boost signals. Should this also be carried over? I can complete a patch and submit a track item in the next couple of days.
I would suggest "adapting" bind's tuples to fusion instead of replacing it with fusion's vector/list. The main advantage of adapting is that it is non-intrusive. Remember that one of bind's biggest advantage over lambda/phoenix is that it works with a lot more compilers. Alas, fusion requires a fairly conforming compiler. Once you adapt bind's tuples to fusion, you can now use its facilities (algorithms, etc.) for free. (for an example of how to adapt an existing sequence/tuple over to fusion, check out boost/fusion/sequence/adapted/boost_tuple/ and friends.)
PS: I've also done the same change with phoenix::tuple so whichever one is preferred
FYI, the latest phoenix version already uses fusion. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
-----Original Message----- From: boost-bounces@lists.boost.org on behalf of Joel de Guzman I would suggest "adapting" bind's tuples to fusion instead of replacing it with fusion's vector/list. The main advantage of adapting is that it is non-intrusive. Remember that one of bind's biggest advantage over lambda/phoenix is that it works with a lot more compilers. Alas, fusion requires a fairly conforming compiler. Once you adapt bind's tuples to fusion, you can now use its facilities (algorithms, etc.) for free. -------------- Ah, you are right. My apologies to Peter. --------------
PS: I've also done the same change with phoenix::tuple so whichever one is preferred
FYI, the latest phoenix version already uses fusion. ------ Really? Well anyway, thank you for your wisdom :) Sohail
Sohail Somani wrote:
-----Original Message----- From: boost-bounces@lists.boost.org on behalf of Joel de Guzman
I would suggest "adapting" bind's tuples to fusion instead of replacing it with fusion's vector/list. The main advantage of adapting is that it is non-intrusive. Remember that one of bind's biggest advantage over lambda/phoenix is that it works with a lot more compilers. Alas, fusion requires a fairly conforming compiler. Once you adapt bind's tuples to fusion, you can now use its facilities (algorithms, etc.) for free.
--------------
Ah, you are right. My apologies to Peter.
No worries :) I'm sure no apology is needed. Anyway, I really encourage you to pursue this. It would be a good addition to fusion/sequence/adapted. Such an effort would be highly beneficial to all. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
participants (4)
-
Joel de Guzman -
John Fletcher -
Peter Dimov -
Sohail Somani