Subject: Re: [boost] [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?
From: Kris (krzysztof_at_[hidden])
Date: 2016-02-08 15:48:08
On Sun, Feb 7, 2016 at 5:01 PM, Rob Stewart [via Boost] <
> 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:
> d = s + e[g]/a
> s + e[g]/a = d
> d << s + e[g]/a
> s + e[g]/a >> d
> The choices are limited. Another pair that comes to mind is <= and ->.
> 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:
> 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
> 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.
> 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
I will try to work on '->', maybe it's possible, it is C++ in the end.
> (Sent from my portable computation engine)
> Unsubscribe & other changes:
> If you reply to this email, your message will be added to the discussion
> 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
-- View this message in context: http://boost.2283326.n4.nabble.com/MSM-Is-there-any-interest-in-C-14-Boost-MSM-eUML-like-library-which-compiles-up-to-60x-quicker-whils-tp4683016p4683330.html Sent from the Boost - Dev mailing list archive at Nabble.com.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk