Re: expected_function

>>> We can probably do it in separate PRs, starting with the expect 
directive
>>> perhaps?
>>
>> That's a good point to start with for me to get confident with the 
procedures. I'd fork
>> spirit, add the operator, move it into the qi namespace, adjust example 
and test.
>> Regarding the docs I'll have to look how they are done. I'll take the 
existing directives
>> doc as a spec. Ok so far?

> Sounds good!

I prepared the PR so far. There are some issues left which I would like to 
discuss
before I actually raise the PR to make sure it is acceptable. Here is what 
I did.

1. Moved the directive to the qi namespace. Tested, ok.

2. Registered expect as a common terminal in spirit 
(home/support/common_terminals.hpp)
   This introduced an issue, because the qi expectation operator's > 
implementation is
       in a struct called 'expect'. To fix this, I reordered the headers 
in home/qi.hpp.
   The operator.hpp is now included first and then the directive.hpp. 
Works.

       Obviously the cleanest solution would be to change the expectation 
operator's struct
   to 'expect_operator' which would make header reordering obsolete.

  This is not likely to break client code. But if one derived a class from 
expectation
  operator's expect struct, this could break. I can not imagine any reason 
why one could 
  have done that. The 

  Please advice.

3. Created test code and introduced it to according jamfile. Tested, ok.

4. Created forwarding header qi_expectd.hpp in include. Forwards to 
home/qi/directive/expect.hpp.

5. Created example code and introduced it to according jamfile.
 
   I took the example from my qitoo repo. Do we actually need that example 
code? There is no
   example code demonstrating the expectation operator. And the expect 
directive is somewhat
   self-explaining, so fmo we don't need this.

   Please advice.

6. Created documentation by adding the expect directive doc to 
doc/qi/directive.qbk.

   I have got at problem to produce html output of that. When I bjam --v2 
--enable-index the
   documentation, only a spiritv2.boostbook gets produced, not the final 
html. Do you have
   an idea, what I am missing here?

   Please advice.

So, I learned a lot about the Boost build environment. :)

Regards, Frank 

>>> That way, we can do a thorough review. Also, I'm not yet sure if
>>> all the additional components can make it into the codebase. expect is
>>> definitely an important addition. probe is interesting, but I'm not 
100%
>>> sure about what it really is and its significance.
>>
>> Probe does in effect the same as the existing hold directive. It does 
attribute rollback
>> if the expression fails to parse. Hold accomplishes that by creating a 
temporary attribute
>> and swapping that in on success. So it requires swap to be implemented 
for the attribute
>> type.
>>
>> Probe on the other hand does not produce a temporary atrribute. It 
parses lookahead once
>> and on success a second time producing the attribute. No swap 
implementation necessary. So
>> it can be savely applied even on intermediates like expr >> hold[expr] 
without having the
>> intermediate attribute type explicitly defined.
>>
>> Pro hold: Parses once, no buffering, speed
>> Inconvenience: Swap impl. necessary
>> Effort: Parse (fail), parse + swap ( success)
>>
>> Pro probe: No swap, applicable to intermediates
>> Cons: Lookahead
>> Effort: Parse ( fail), parse twice (success)
>>
>> Probe is easier to use, so in parser development probe could be the 
choice, while the
>> final runtime optimized version would employ hold.
>
> OK, I get it. I don't quite understand though why it is easier to use?
>
>>> operator / would be
>>> quite useful in certain contexts, but it can already be done using 
some
>>> other means, no?
>>
>> It can be done otherwise.  id / string("::") can be expressed as id >> 
*(string("id") >> id).
>> / can parse a superset of %. So is id % expr the same as id / 
omit[expr]. / does attribute
>> rollback on failure.
>>
>>> I'll also have to ask you to maintain your code and provide support 
for
>>> it. Oh and the docs will have to be properly integrated, just like any
>>> other component in Qi. So, in the end, it won't be an easy ride for 
you,
>>> but if you are willing to go the whole nine yards, then I am all for 
it.
>>
>> Ok. My time is dedicated to tec research alone nowerdays. Live is a 
joy. :) That's not all
>> about parsing but I am willing to put effort in this.
>>
>>> How about we go try it out with expect directive first? That is an 
easy
>>> one.
>>
>> Yes, sure. Are the steps described above correct?
>
>Correct.
>
>> I have some other things ready, but I did not manage to finalize the 
docs and tests before
>> my vacation began. I am back in July. I extended qi to support 
operators of higher arity.
>> A ternary conditional operator called if_ is available. This enables 
for example the
>> Nabialek trick (just without trick). I think, qitoo is a nice test bed 
for such proposals.
>>
>> Looking forward to start. :)

>Wonderful! Seems you know your way around Qi!
>
>Regards,
>-- 
>Joel de Guzman

------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape

_______________________________________________
Spirit-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/spirit-general