[GSoC] Helping out Phoenix v3
Joel and I pondered about getting a student from GSoC to help us complete the phoenix v3 port to proto. I currently have a few prototypes and ideas to extend it further but a few more hands are most welcome. Considering the schedule, I'll be compeltely free for mentoring this prospective student. Now, is it realistic and on topic for GSoC ?
Joel and I pondered about getting a student from GSoC to help us complete the phoenix v3 port to proto. I currently have a few prototypes and ideas to extend it further but a few more hands are most welcome. Considering the schedule, I'll be compeltely free for mentoring this prospective student.
Great!
Now, is it realistic and on topic for GSoC ?
I think it should be fine if the projects have well-defined goals. If the ideas are a little vague, then the proposals will tend to be vague also :) Do you want to add your projects to the idea page ( https://svn.boost.org/trac/boost/wiki/SoC2010)? Andrew Sutton andrew.n.sutton@gmail.com
Andrew Sutton wrote:
I think it should be fine if the projects have well-defined goals. If the ideas are a little vague, then the proposals will tend to be vague also :)
OK
Do you want to add your projects to the idea page ( https://svn.boost.org/trac/boost/wiki/SoC2010)?
Thing is I don't have any login for there ;)
Do you want to add your projects to the idea page (
Thing is I don't have any login for there ;)
Isn't it the same as your svn login? If not, send me an email with the proposal and I'll stick it up there. Andrew Sutton andrew.n.sutton@gmail.com
Ok, I added a short blurb. Maybe Harmut or Joel could add more but that's the basic. -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35
Ok, I added a short blurb. Maybe Harmut or Joel could add more but that's the basic.
Great! Thanks, Joel. Just one quick note... It would probably be better to refer to the software in gender neutral terms (as opposed to "his" or "her"). You never know when somebody is going to put on their political correctness hat :) I tweaked the wording a little. Andrew Sutton andrew.n.sutton@gmail.com
Andrew Sutton wrote:
Great! Thanks, Joel.
Just one quick note... It would probably be better to refer to the software in gender neutral terms (as opposed to "his" or "her"). You never know when somebody is going to put on their political correctness hat :) I tweaked the wording a little.
That's probably my frenglish that became apparent :p -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35
Just one quick note... It would probably be better to refer to the software
in gender neutral terms (as opposed to "his" or "her"). You never know when somebody is going to put on their political correctness hat :) I tweaked the wording a little.
That's probably my frenglish that became apparent :p
I guess I'm guilty of being culturally insensitive ;) Andrew Sutton andrew.n.sutton@gmail.com
On 3/13/2010 1:00 AM, joel falcou wrote:
Ok, I added a short blurb. Maybe Harmut or Joel could add more but that's the basic.
Great! Thanks, Joel for posting this. Also, take note that one of the successful GSoc 2009 project was porting Fusion to C++0x (mentored by Hartmut). Christopher Schmidt did a such wonderful job on this as did Hartmut as mentor. I'd be willing to co-mentor this as well. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net http://www.facebook.com/djowel Meet me at BoostCon http://www.boostcon.com/home http://www.facebook.com/boostcon
Ok, I added a short blurb. Maybe Harmut or Joel could add more but
that's the basic.
Great! Thanks, Joel for posting this. Also, take note that one of the successful GSoc 2009 project was porting Fusion to C++0x (mentored by Hartmut). Christopher Schmidt did a such wonderful job on this as did Hartmut as mentor.
This is actually why I added the "port your favorite library" project. If any of these results are as good as last year's, then it's a worthwhile project
I'd be willing to co-mentor this as well.
Excellent! I'll put you on the list in a co-mentoring role. Thanks everybody, Andrew Sutton andrew.n.sutton@gmail.com
Hi, I am preparing a proposal for a Boost.Phoenix GSoC. I have been willing to work on this library for a long time now -- being in touch with the two Joel's about that -- but never took the time. My motivation is clearly to provide a clean functional programming library for Boost, with all its advantages. I have been experimenting with strongly and statically typed functional programming languages for a while now and thus have been able to see how the functional programming paradigm helps (this will be detailed in my proposal). Moreover, I have been following closely Joel (Falcou)'s and Eric Niebler's prototypes and am aware of the power Boost.Proto offers. My background and interests in doing this will also be detailed in the proposal. I should be able to privide you with a draft of the proposal today. On Fri, Mar 12, 2010 at 8:59 AM, Joel Falcou <joel.falcou@lri.fr> wrote:
Joel and I pondered about getting a student from GSoC to help us complete the phoenix v3 port to proto. I currently have a few prototypes and ideas to extend it further but a few more hands are most welcome. Considering the schedule, I'll be compeltely free for mentoring this prospective student.
Now, is it realistic and on topic for GSoC ? _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Alp Mestanogullari http://alpmestan.wordpress.com/ http://alp.developpez.com/
On Tue, Mar 30, 2010 at 4:32 AM, Alp Mestanogullari <alp@mestan.fr> wrote:
Hi,
I am preparing a proposal for a Boost.Phoenix GSoC. I have been willing to work on this library for a long time now -- being in touch with the two Joel's about that -- but never took the time. My motivation is clearly to provide a clean functional programming library for Boost, with all its advantages. I have been experimenting with strongly and statically typed functional programming languages for a while now and thus have been able to see how the functional programming paradigm helps (this will be detailed in my proposal). Moreover, I have been following closely Joel (Falcou)'s and Eric Niebler's prototypes and am aware of the power Boost.Proto offers. My
I saw Joel's previous comment about posting his prototype online somewhere. Joel, did you do that already? Manjunath
Manjunath Kudlur wrote:
I saw Joel's previous comment about posting his prototype online somewhere. Joel, did you do that already?
i'll do so as soon as i extracted it from the other project I use it in aka pretty soon. -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35
A bit late, but you can find my proposal for a Boost.Phoenix GSoC here : http://mestan.fr/phoenix_proposal.pdf On Tue, Mar 30, 2010 at 1:32 PM, Alp Mestanogullari <alp@mestan.fr> wrote:
Hi,
I am preparing a proposal for a Boost.Phoenix GSoC. I have been willing to work on this library for a long time now -- being in touch with the two Joel's about that -- but never took the time. My motivation is clearly to provide a clean functional programming library for Boost, with all its advantages. I have been experimenting with strongly and statically typed functional programming languages for a while now and thus have been able to see how the functional programming paradigm helps (this will be detailed in my proposal). Moreover, I have been following closely Joel (Falcou)'s and Eric Niebler's prototypes and am aware of the power Boost.Proto offers. My background and interests in doing this will also be detailed in the proposal.
I should be able to privide you with a draft of the proposal today.
On Fri, Mar 12, 2010 at 8:59 AM, Joel Falcou <joel.falcou@lri.fr> wrote:
Joel and I pondered about getting a student from GSoC to help us complete the phoenix v3 port to proto. I currently have a few prototypes and ideas to extend it further but a few more hands are most welcome. Considering the schedule, I'll be compeltely free for mentoring this prospective student.
Now, is it realistic and on topic for GSoC ? _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Alp Mestanogullari http://alpmestan.wordpress.com/ http://alp.developpez.com/
-- Alp Mestanogullari http://alpmestan.wordpress.com/ http://alp.developpez.com/
Ok, ppl may look at : https://www.lri.fr/svn/parall/prog_gen/branches/phoenix3/ login/passwd : boost/boost to get a look at how I see the internals of the new phoenix working. The code is just a proto transform that evaluate any kind of expression and values from a fusion vector in a recursive, customizable way. Basically, it needs to be wrapped into a proper proto grammar+ expression to hide that. Now, if you wanted to add for exampel a if_[] statement and have it evaluated properly you can overload either the evaluate PFO or specialize process_node. If you need to do otherthign with the expression, build a new evlauator like PFO and build another compile<T> instance (like coutning arity, turn the expression into a std::string, etc). You will notice that both the process_node and evaluator are proto agnostic. I'll advice using make_expr over const object to reduce compile-time (as stated in a old post of mine) and maybe use CRTP so we can imbue placeholder with proper method generating expression.
On 4/2/2010 11:43 PM, Joel Falcou wrote:
Ok, ppl may look at :
https://www.lri.fr/svn/parall/prog_gen/branches/phoenix3/
login/passwd : boost/boost
to get a look at how I see the internals of the new phoenix working. The code is just a proto transform that evaluate any kind of expression and values from a fusion vector in a recursive, customizable way.
Basically, it needs to be wrapped into a proper proto grammar+ expression to hide that.
Now, if you wanted to add for exampel a if_[] statement and have it evaluated properly you can overload either the evaluate PFO or specialize process_node.
If you need to do otherthign with the expression, build a new evlauator like PFO and build another compile<T> instance (like coutning arity, turn the expression into a std::string, etc). You will notice that both the process_node and evaluator are proto agnostic.
I'll advice using make_expr over const object to reduce compile-time (as stated in a old post of mine) and maybe use CRTP so we can imbue placeholder with proper method generating expression.
Joel, this is a wonderful start. I'll peruse the code when I get some time. Let me add though that would be candidates study the phoenix code very well. The last thing we would want to do is rewrite everything from scratch. That's not my intent and that would be foolish. The strategy is to port the "core" plus the extension mechanism to proto. By doing so, the rest would follow nicely. That's what Eric (Niebler) did in his initial port. I would insist not to wander too far from Eric's initial port, so I suggest studying his code as well. CC'ing Eric. Eric, could you send me the latest and the greatest of your port for me to upload it somewhere prominent? Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net http://www.facebook.com/djowel Meet me at BoostCon http://www.boostcon.com/home http://www.facebook.com/boostcon
On 4/2/2010 6:42 PM, Joel de Guzman wrote:
Eric, could you send me the latest and the greatest of your port for me to upload it somewhere prominent?
My first attempt at a proto/phoenix port is in boost svn at branches/proto/v4/boost/phoenix, but that was only ~80% finished, and ultimately abandoned because I thought the architecture was poor. I had planned to start from scratch and was prepared to make any changes necessary to proto to fully support a clean phoenix design with good compile times, but never got much further than the mini-phoenix that I posted to the wiki here: https://svn.boost.org/trac/boost/attachment/wiki/BoostPhoenix3/miniphoenix.c... There are other musing on the wiki that any GSoC candidate should read. https://svn.boost.org/trac/boost/wiki/BoostPhoenix3 -- Eric Niebler BoostPro Computing http://www.boostpro.com
On 4/2/2010 7:05 PM, Eric Niebler wrote:
On 4/2/2010 6:42 PM, Joel de Guzman wrote:
Eric, could you send me the latest and the greatest of your port for me to upload it somewhere prominent?
My first attempt at a proto/phoenix port is in boost svn at branches/proto/v4/boost/phoenix, but that was only ~80% finished, and ultimately abandoned because I thought the architecture was poor.
I had planned to start from scratch and was prepared to make any changes necessary to proto to fully support a clean phoenix design with good compile times, but never got much further than the mini-phoenix that I posted to the wiki here:
https://svn.boost.org/trac/boost/attachment/wiki/BoostPhoenix3/miniphoenix.c...
I've uploaded a simplified and cleaner version of this prototype here: https://svn.boost.org/trac/boost/attachment/wiki/BoostPhoenix3/miniphoenix2.... It requires proto on boost trunk. At some point, I'll need to add to proto a hook to make it simpler to customize the terminal capture behavior. -- Eric Niebler BoostPro Computing http://www.boostpro.com
I had planned to start from scratch and was prepared to make any changes necessary to proto to fully support a clean phoenix design with good compile times, but never got much further than the mini-phoenix that I posted to the wiki here:
https://svn.boost.org/trac/boost/attachment/wiki/BoostPhoenix3/miniphoenix.c...
I've uploaded a simplified and cleaner version of this prototype here:
https://svn.boost.org/trac/boost/attachment/wiki/BoostPhoenix3/miniphoenix2....
Oh yeah, this is waaay simpler with PROTO_EXTENDS_MEMBERS. Just a thought, is having a if_ - elsif_ - else_ construct added to phoenix useful? It's definitely more convenient than just if_ - else_ construct. Manjunath
On 4/29/2010 11:06 AM, Manjunath Kudlur wrote:
Just a thought, is having a if_ - elsif_ - else_ construct added to phoenix useful? It's definitely more convenient than just if_ - else_ construct.
No strong feelings. I wouldn't worry about it now. It can always be added later. -- Eric Niebler BoostPro Computing http://www.boostpro.com
On Thursday 29 April 2010 19:54:03 Eric Niebler wrote:
On 4/2/2010 7:05 PM, Eric Niebler wrote:
On 4/2/2010 6:42 PM, Joel de Guzman wrote:
Eric, could you send me the latest and the greatest of your port for me to upload it somewhere prominent?
My first attempt at a proto/phoenix port is in boost svn at branches/proto/v4/boost/phoenix, but that was only ~80% finished, and ultimately abandoned because I thought the architecture was poor.
I had planned to start from scratch and was prepared to make any changes necessary to proto to fully support a clean phoenix design with good compile times, but never got much further than the mini-phoenix that I posted to the wiki here:
https://svn.boost.org/trac/boost/attachment/wiki/BoostPhoenix3/miniphoeni x.cpp
I've uploaded a simplified and cleaner version of this prototype here:
https://svn.boost.org/trac/boost/attachment/wiki/BoostPhoenix3/miniphoenix2 .cpp
It requires proto on boost trunk. At some point, I'll need to add to proto a hook to make it simpler to customize the terminal capture behavior.
Thanks for the update. I will have to examine it more closely. On first sight it looks very clean. What i miss is the easy extentability. Do you have an idea for that? I am currently working on getting Joel Falcous more phoenix like. After that, i think i will want to merge your two approaches. What do you think?
On 4/29/2010 10:41 PM, Thomas Heller wrote:
On Thursday 29 April 2010 19:54:03 Eric Niebler wrote:
I've uploaded a simplified and cleaner version of this prototype here:
https://svn.boost.org/trac/boost/attachment/wiki/BoostPhoenix3/miniphoenix2....
It requires proto on boost trunk. At some point, I'll need to add to proto a hook to make it simpler to customize the terminal capture behavior.
Thanks for the update. I will have to examine it more closely. On first sight it looks very clean. What i miss is the easy extentability. Do you have an idea for that? I am currently working on getting Joel Falcous more phoenix like. After that, i think i will want to merge your two approaches. What do you think?
Sorry for the delayed response. Extensibility is the strength of this phoenix design. Notice that it takes only about 80 lines of code to implement the core of phoenix. Even the placeholders are implemented as non-invasive extensions of this core. It's an open question whether it's desirable to hide the proto bits when exposing these customization points, and if so, what that would look like. -- Eric Niebler BoostPro Computing http://www.boostpro.com
On 5/4/2010 8:05 AM, Eric Niebler wrote:
On 4/29/2010 10:41 PM, Thomas Heller wrote:
On Thursday 29 April 2010 19:54:03 Eric Niebler wrote:
I've uploaded a simplified and cleaner version of this prototype here:
https://svn.boost.org/trac/boost/attachment/wiki/BoostPhoenix3/miniphoenix2....
It requires proto on boost trunk. At some point, I'll need to add to proto a hook to make it simpler to customize the terminal capture behavior.
Thanks for the update. I will have to examine it more closely. On first sight it looks very clean. What i miss is the easy extentability. Do you have an idea for that? I am currently working on getting Joel Falcous more phoenix like. After that, i think i will want to merge your two approaches. What do you think?
Sorry for the delayed response. Extensibility is the strength of this phoenix design. Notice that it takes only about 80 lines of code to implement the core of phoenix. Even the placeholders are implemented as non-invasive extensions of this core. It's an open question whether it's desirable to hide the proto bits when exposing these customization points, and if so, what that would look like.
Thomas, as main architect of Phoenix, I'd like to take charge in developing the core of Phoenix. Please give me some time though. Right now I'm focused on BoostCon. Next week, at BoostCon, I'll find some time to come up with an overall strategy on how we'll tackle this. At any rate, I do admire your enthusiasm. Please keep it up! :-) Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net http://www.facebook.com/djowel Meet me at BoostCon http://www.boostcon.com/home http://www.facebook.com/boostcon
On Tuesday 04 May 2010 05:31:54 Joel de Guzman wrote:
On 5/4/2010 8:05 AM, Eric Niebler wrote:
On 4/29/2010 10:41 PM, Thomas Heller wrote:
On Thursday 29 April 2010 19:54:03 Eric Niebler wrote:
I've uploaded a simplified and cleaner version of this prototype here:
https://svn.boost.org/trac/boost/attachment/wiki/BoostPhoenix3/miniphoe nix2.cpp
It requires proto on boost trunk. At some point, I'll need to add to proto a hook to make it simpler to customize the terminal capture behavior.
Thanks for the update. I will have to examine it more closely. On first sight it looks very clean. What i miss is the easy extentability. Do you have an idea for that? I am currently working on getting Joel Falcous more phoenix like. After that, i think i will want to merge your two approaches. What do you think?
Sorry for the delayed response. Extensibility is the strength of this phoenix design. Notice that it takes only about 80 lines of code to implement the core of phoenix. Even the placeholders are implemented as non-invasive extensions of this core. It's an open question whether it's desirable to hide the proto bits when exposing these customization points, and if so, what that would look like.
Thomas, as main architect of Phoenix, I'd like to take charge in developing the core of Phoenix. Please give me some time though. Right now I'm focused on BoostCon. Next week, at BoostCon, I'll find some time to come up with an overall strategy on how we'll tackle this.
At any rate, I do admire your enthusiasm. Please keep it up! :-)
Alright. I will be happy to share my thoughts i donated to phoenix in the last weeks, and postpone my experiments with the prototypes.
On 5/4/2010 1:22 PM, Thomas Heller wrote:
On Tuesday 04 May 2010 05:31:54 Joel de Guzman wrote:
On 5/4/2010 8:05 AM, Eric Niebler wrote:
On 4/29/2010 10:41 PM, Thomas Heller wrote:
On Thursday 29 April 2010 19:54:03 Eric Niebler wrote:
I've uploaded a simplified and cleaner version of this prototype here:
https://svn.boost.org/trac/boost/attachment/wiki/BoostPhoenix3/miniphoe nix2.cpp
It requires proto on boost trunk. At some point, I'll need to add to proto a hook to make it simpler to customize the terminal capture behavior.
Thanks for the update. I will have to examine it more closely. On first sight it looks very clean. What i miss is the easy extentability. Do you have an idea for that? I am currently working on getting Joel Falcous more phoenix like. After that, i think i will want to merge your two approaches. What do you think?
Sorry for the delayed response. Extensibility is the strength of this phoenix design. Notice that it takes only about 80 lines of code to implement the core of phoenix. Even the placeholders are implemented as non-invasive extensions of this core. It's an open question whether it's desirable to hide the proto bits when exposing these customization points, and if so, what that would look like.
Thomas, as main architect of Phoenix, I'd like to take charge in developing the core of Phoenix. Please give me some time though. Right now I'm focused on BoostCon. Next week, at BoostCon, I'll find some time to come up with an overall strategy on how we'll tackle this.
At any rate, I do admire your enthusiasm. Please keep it up! :-)
Alright. I will be happy to share my thoughts i donated to phoenix in the last weeks, and postpone my experiments with the prototypes.
No, please don't. Experimentation does not hurt at all. It'll give you a good feel for the library :-) Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net http://www.facebook.com/djowel Meet me at BoostCon http://www.boostcon.com/home http://www.facebook.com/boostcon
On Tuesday 04 May 2010 02:05:03 Eric Niebler wrote:
On 4/29/2010 10:41 PM, Thomas Heller wrote:
On Thursday 29 April 2010 19:54:03 Eric Niebler wrote:
I've uploaded a simplified and cleaner version of this prototype here:
https://svn.boost.org/trac/boost/attachment/wiki/BoostPhoenix3/miniphoen ix2.cpp
It requires proto on boost trunk. At some point, I'll need to add to proto a hook to make it simpler to customize the terminal capture behavior.
Thanks for the update. I will have to examine it more closely. On first sight it looks very clean. What i miss is the easy extentability. Do you have an idea for that? I am currently working on getting Joel Falcous more phoenix like. After that, i think i will want to merge your two approaches. What do you think?
Sorry for the delayed response. Extensibility is the strength of this phoenix design. Notice that it takes only about 80 lines of code to implement the core of phoenix. Even the placeholders are implemented as non-invasive extensions of this core. It's an open question whether it's desirable to hide the proto bits when exposing these customization points, and if so, what that would look like.
After playing a little bit with your prototype I saw exactly what you mean. Plus, the question wether to hide proto details completly (if that is even possible) is quite complicated. After seeing your work I think we should not aim for that. I tried to combine the two different approaches and what i realised was, that most stuff was handled automatically by proto already.
Thomas Heller wrote:
After playing a little bit with your prototype I saw exactly what you mean. Plus, the question wether to hide proto details completly (if that is even possible) is quite complicated. After seeing your work I think we should not aim for that. I tried to combine the two different approaches and what i realised was, that most stuff was handled automatically by proto already It may just mean my initial design was not that fitted there ;)
-- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35
I will have to examine it more closely. On first sight it looks very clean. What i miss is the easy extentability. Do you have an idea for that? I am currently working on getting Joel Falcous more phoenix like. After that, i think i will want to merge your two approaches. What do you think?
Sorry for the delayed response. Extensibility is the strength of this phoenix design. Notice that it takes only about 80 lines of code to implement the core of phoenix. Even the placeholders are implemented as non-invasive extensions of this core. It's an open question whether it's desirable to hide the proto bits when exposing these customization points, and if so, what that would look like.
After playing a little bit with your prototype I saw exactly what you mean. Plus, the question wether to hide proto details completly (if that is even possible) is quite complicated. After seeing your work I think we should not aim for that. I tried to combine the two different approaches and what i realised was, that most stuff was handled automatically by proto already.
Even if I'm only remotely connected to this I would like to emphasize the importance of a simple extension interface. By 'simple' I mean: hide Proto! We do not need the full power of Proto here and forcing every user to understand Proto's fine details before he is able to write his own actor is not good. Yes, it is possible to hide Proto completely behind a set of well-crafted domain specific (i.e. Phoenix) interfaces. This has been done already in Spirit (V2) and has proven to work well. Regards Hartmut --------------- Meet me at BoostCon www.boostcon.com
Hartmut Kaiser wrote:
Even if I'm only remotely connected to this I would like to emphasize the importance of a simple extension interface. By 'simple' I mean: hide Proto! We do not need the full power of Proto here and forcing every user to understand Proto's fine details before he is able to write his own actor is not good. Yes, it is possible to hide Proto completely behind a set of well-crafted domain specific (i.e. Phoenix) interfaces. This has been done already in Spirit (V2) and has proven to work well.
That's what Itried to build but maybe my original prototype is not sound enough. -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35
For what it's worth, I definitely think Proto should be hidden, so that people wanting a new actor, or evaluator or whatever, should only care about what they have to redefine in terms of phoenix stuffs, not phoenix's internals (i.e Proto mostly). -- Alp Mestanogullari http://alpmestan.wordpress.com/ http://alp.developpez.com/
On 5/4/2010 4:37 AM, Hartmut Kaiser wrote:
Eric Niebler wrote:
It's an open question whether it's desirable to hide the proto bits when exposing these customization points, and if so, what that would look like.
Even if I'm only remotely connected to this I would like to emphasize the importance of a simple extension interface. By 'simple' I mean: hide Proto! We do not need the full power of Proto here and forcing every user to understand Proto's fine details before he is able to write his own actor is not good. Yes, it is possible to hide Proto completely behind a set of well-crafted domain specific (i.e. Phoenix) interfaces. This has been done already in Spirit (V2) and has proven to work well.
Hartmut, where can I find the documentation for Spirit's extensibility mechanism? -- Eric Niebler BoostPro Computing http://www.boostpro.com
On 5/4/2010 4:37 AM, Hartmut Kaiser wrote:
Eric Niebler wrote:
It's an open question whether it's desirable to hide the proto bits when exposing these customization points, and if so, what that would look like.
Even if I'm only remotely connected to this I would like to emphasize the importance of a simple extension interface. By 'simple' I mean: hide Proto! We do not need the full power of Proto here and forcing every user to understand Proto's fine details before he is able to write his own actor is not good. Yes, it is possible to hide Proto completely behind a set of well-crafted domain specific (i.e. Phoenix) interfaces. This has been done already in Spirit (V2) and has proven to work well.
Hartmut, where can I find the documentation for Spirit's extensibility mechanism?
Ahem... There isn't any :-P At least nothing complete. There are bits and pieces described in several places (like here: http://www.boost.org/doc/libs/1_42_0/libs/spirit/doc/html/spirit/advanced/in depth/parsers_indepth.html and here: http://boost-spirit.com/home/articles/qi-example/creating-your-own-parser-co mponent-for-spirit-qi/), but nothing coherent yet. You'll have to resolve to the source code for now, sorry. Regards Hartmut --------------- Meet me at BoostCon www.boostcon.com
On 5/4/2010 11:25 AM, Hartmut Kaiser wrote:
On 5/4/2010 4:37 AM, Hartmut Kaiser wrote:
Eric Niebler wrote:
It's an open question whether it's desirable to hide the proto bits when exposing these customization points, and if so, what that would look like.
Even if I'm only remotely connected to this I would like to emphasize the importance of a simple extension interface. By 'simple' I mean: hide Proto! We do not need the full power of Proto here and forcing every user to understand Proto's fine details before he is able to write his own actor is not good. Yes, it is possible to hide Proto completely behind a set of well-crafted domain specific (i.e. Phoenix) interfaces. This has been done already in Spirit (V2) and has proven to work well.
Hartmut, where can I find the documentation for Spirit's extensibility mechanism?
Ahem... There isn't any :-P At least nothing complete. There are bits and pieces described in several places (like here:
http://www.boost.org/doc/libs/1_42_0/libs/spirit/doc/html/spirit/advanced/in...
and here:
http://boost-spirit.com/home/articles/qi-example/creating-your-own-parser-co...),
but nothing coherent yet.
You'll have to resolve to the source code for now, sorry.
That's OK. The extensibility mechanism for Phoenix is documented, and I can make my own inferences. The challenge here will be to preserve the strengths of a Proto-based design (a well-defined grammar against which expressions can validated, and clean separation of data structure and algorithm) with a clean extension mechanism. The Phoenix that we know and love is clean and simple, but conflates data structure and algorithm. That may not be an issue -- I can't think of alternate algorithms for lambdas the way I can for parsers and regex engines. But separation of data structure and algorithm is sound design, and I would think twice before giving it up. I foresee some long Phoenix hack sessions in Aspen next week. -- Eric Niebler BoostPro Computing http://www.boostpro.com
participants (9)
-
Alp Mestanogullari -
Andrew Sutton -
Eric Niebler -
Hartmut Kaiser -
Joel de Guzman -
joel falcou -
Joel Falcou
-
Manjunath Kudlur -
Thomas Heller