Re: [Boost-users] [PROTO] Custom functions, scalar terminal and make_expr vs details::as_expr_if

Subject: Re: [Boost-users] [PROTO] Custom functions, scalar terminal and make_expr vs details::as_expr_if
From: Joel Falcou (joel.falcou_at_[hidden])
Date: 2008-11-30 12:55:20

Eric Niebler a écrit :
> With SFINAE, the error your users are likely to see is something like 
> "No such function f(A,B)" followed by an exhaustive list of potential 
> matches. Then your users are left to figure out for themselves why 
> none of those functions are a good match.
>
> In my experience, a message like "E doesn't match the grammar G" is 
> simpler, often shorter, and has the benefit of taking your users to a 
> single line in your code where you can stick a big comment describing 
> *why* the compile-time assertion failed.
>
That's a very valid position. So basically, a good ol'MPL_ASSERT_MSG 
where it fits is better.
> To figure it out, just count template instantiations. You're building 
> a new expression type, so you can't avoid instantiating those types. 
> But make_expr is itself a template, and you can avoid that cost.
>
Indeed, I just did the math and the comparison (went down from 9 to 3s)

> There's one more thing I wanted to say about this. No, it doesn't 
> defeat Proto's purpose. Proto provides high-level facilities so you 
> can do a lot in just a little code. This is very important when you 
> are just starting out with your DSEL and your code is in flux. Use 
> those high-level facilities to keep your design fungible. When you're 
> happy with your design, *then* you can go back and optimize for 
> compile times by replacing some of the more expensive facilities with 
> more efficient lower-level ones.
>
> A good example of this is transforms. Joel is using composite 
> transforms (object and callable transforms, specified with function 
> types) when building Spirit2x. It makes the code very small and 
> nimble, and he can easily change his mind and make radical changes at 
> this stage. When things are stable, he'll go through and replace all 
> the composite transforms with custom primitive transforms to improve 
> compile times. Does that mean composite transforms are useless? Not at 
> all.
The fact is that I was running my own DSL for years now using hand made 
code and lots of those 'low level' structures. I first saw Proto as a 
'end-all' solution. I obviously miss the largest benefit of Proto design 
which is indeed going down low level when needed.
OK, things are sensibly clearer now. Using the low level constructor was 
something I thought was frowned upon. Guess I was wrong.
I'll then wait for my design to stabilize, cope with compiel-time for a 
few and do as you said. Thanks you very much.

Thanks for this valuable insight.

-- 
___________________________________________
Joel Falcou - Assistant Professor
PARALL Team - LRI - Universite Paris Sud XI
Tel : [phone]
-- 
___________________________________________
Joel Falcou - Assistant Professor
PARALL Team - LRI - Universite Paris Sud XI
Tel : [phone]