On Sun, Feb 7, 2016 at 5:01 PM, Rob Stewart [via Boost] < ml-node+s2283326n4683304h43@n4.nabble.com> wrote:
On February 6, 2016 3:59:30 PM EST, Kris <[hidden email] <http:///user/SendEmail.jtp?type=node&node=4683304&i=0>> wrote:
I have encountered one ackward thing with the usage of [shift operators] with data events.
src + event<some_event_data> >> dst // '> >>' is quite unfortunate combination here
How ironic. We got a new rule in the language to allow for multiple >'s to be considered template argument list delimiters, but it won't help here. Such are the problems of EDSLs.
Heheh, true that.
So far, we have these options:
1) d = s + e[g]/a s + e[g]/a = d
2) d << s + e[g]/a s + e[g]/a >> d
The choices are limited. Another pair that comes to mind is <= and ->.
3) d <= s + e[g]/a s + e[g]/a -> d
Those are directional and the = vs. - asymmetry might be a good thing.
That's is a winner for me! However, I don't think it is possible to implement, is it? `->` is not really user friendly for writing DSLs. Or maybe, like that, but that is even harder to achieve. d <- s + e[g]/a s + e[g]/a -> d
The last pair I can suggest is the following:
4) d = s + e[g]/a s + e[g]/a -> d
1) is strange given that we expect assignment to be to the expression on the LHS.
Yea, its a fair point. '<<', '<-' seems to be better for the dst - src option.
2) has the template argument list and shift operator parsing issue. I always put a space on either side of binary operators, so that wouldn't actually affect me.
I like this option, but I find it extremly ackward to have following notation - src + exception<std::runtime_error> >> dst
3) is only troubling due to the asymmetry in the number of lines between = and -.
Yea, it's defo a decent option. I would gladly choose this option, but I don't think '->' is easy to achieve.
4) involves normal assignment semantics in the one case and evokes the new return type function syntax in the other.
True.
The imbalance between the syntaxes for 3) and 4) may not be a big deal since users will adopt one or the other. An issue arises when reading our maintaining the code of someone using the opposite syntax, of course.
My favorite of these is 2).
Thank you for the analysis. It's extremely useful. IMHO s + e[g]/a ->d is the winner for the postfix notation as it follows UML notation and has a direction. However, I don't think is achievable. Well, at least I don't have any idea how to do it :( If it comes to the prefix notation, I guess, '<=', "<<" are the options to choose from. I will try to work on '->', maybe it's possible, it is C++ in the end.
___ Rob
(Sent from my portable computation engine)
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
------------------------------ If you reply to this email, your message will be added to the discussion below:
http://boost.2283326.n4.nabble.com/MSM-Is-there-any-interest-in-C-14-Boost-M... To unsubscribe from [MSM] Is there any interest in C++14 Boost.MSM-eUML like library which compiles up to 60x quicker whilst being a slightly faster too?, click here <http://boost.2283326.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4683016&code=a3J6eXN6dG9mQGp1c2lhay5uZXR8NDY4MzAxNnwtMTY0MTkzNTIwMA==> . NAML <http://boost.2283326.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
-- View this message in context: http://boost.2283326.n4.nabble.com/MSM-Is-there-any-interest-in-C-14-Boost-M... Sent from the Boost - Dev mailing list archive at Nabble.com.