Boost logo

Boost :

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] <
ml-node+s2283326n4683304h43_at_[hidden]> 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-MSM-eUML-like-library-which-compiles-up-to-60x-quicker-whils-tp4683016p4683304.html
> 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-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