question about fusion concepts/documentation

newer
[Test] can one run a specific test...

older
boost::serialization problem with...

Robert Ramey

29 May 2011 29 May '11

10:05 p.m.

I'm working on a personal project based on fusion. This project builds a library on I'm working on an experimental library which builds on fusion. As part of that I want to implement concept checking for this experimental library. Since this builds on fusion, I want to implement concept checking for fusion so my library can build on that. Since fusion seems clearly documented, I would hope that this would be a fairly straight forward exercise. This will also give me a better feel for concept checking and archtypes. Looking at fusion documentation on page: ..libs/fusion/doc/html/fusion/iterator/concepts/forward_iterator.html I find: Expression Requirments ====================== next(i) ... Meta Expressions ============ result_of::next::type ... Expression Semantics =============== next(i) - An iterator to the element following i ... So the quesion is: Why is result_of::next::type necessary? The expression symantics only make sense if next(i) if it returns the same type as it's argument. So why is the result_of::next::type needed at all. That is won't it always be equal to I. If not, why not? The question I have applies to other functions as well but next illustrates my question. specifially I have the same question regarding advance, and advance_c. Also the espressions i == j should return a value convertible to bool. Then what is result_of::equal_to::type to be used for? distance raises similar quesions. I'm actually having quite a bit of difficulty with this task - the above quesions are only the easiest one to formulate. Robert Ramey

Show replies by date

Steven Watanabe

29 May 29 May

10:23 p.m.

AMDG On 05/29/2011 03:05 PM, Robert Ramey wrote:

...

I'm working on a personal project based on fusion. This project builds a library on

I'm working on an experimental library which builds on fusion. As part of that I want to implement concept checking for this experimental library. Since this builds on fusion, I want to implement concept checking for fusion so my library can build on that. Since fusion seems clearly documented, I would hope that this would be a fairly straight forward exercise.

This will also give me a better feel for concept checking and archtypes.

Looking at fusion documentation on page: ..libs/fusion/doc/html/fusion/iterator/concepts/forward_iterator.html I find:

Expression Requirments ====================== next(i) ...

Meta Expressions ============ result_of::next::type ...

Expression Semantics =============== next(i) - An iterator to the element following i ...

So the quesion is: Why is result_of::next::type necessary? The expression symantics only make sense if next(i) if it returns the same type as it's argument. So why is the result_of::next::type needed at all. That is won't it always be equal to I. If not, why not?

The type of next(i) is not the same as the type of i. Every iterator to a fusion sequence has a different type. For example, for fusion::vector, the iterators could look something like: template struct vector_iterator; template vector_iterator next(vector_iterator);

...

The question I have applies to other functions as well but next illustrates my question. specifially I have the same question regarding advance, and advance_c.

Also the espressions i == j should return a value convertible to bool. Then what is result_of::equal_to::type to be used for? distance raises similar quesions.

Actually, result_of::equal_to is used a lot more when implementing algorithms than operator==. equality for fusion iterators depends only on their types. distance can be computed at compile time.

...

I'm actually having quite a bit of difficulty with this task - the above quesions are only the easiest one to formulate.

In Christ, Steven Watanabe

Gordon Woodhull

11 p.m.

On May 29, 2011, at 6:05 PM, Robert Ramey wrote:

...

Expression Requirments ====================== next(i) ...

Meta Expressions ============ result_of::next::type ...

Expression Semantics =============== next(i) - An iterator to the element following i ...

So the quesion is: Why is result_of::next::type necessary? The expression symantics only make sense if next(i) if it returns the same type as it's argument. So why is the result_of::next::type needed at all. That is won't it always be equal to I. If not, why not?

That's exactly it - Fusion has compile-time heterogeneous sequences, so the elements will probably be of different types, and the incremented iterator is always of a different type. This is something I need too, as I'm working on the proposed Fusion.Graph, so I need to define BGL-like concepts on top of Fusion concepts. I imagine you would look at how concepts are defined for metafunctions; I haven't looked at the Concept Check library. (Hoping that Matt Calabrese's proposed Boost.Generic will be up and running later this year!) Cheers, Gordon

Matt Calabrese

30 May 30 May

3:02 p.m.

On Sun, May 29, 2011 at 7:00 PM, Gordon Woodhull wrote:

...

(Hoping that Matt Calabrese's proposed Boost.Generic will be up and running later this year!)

If you have a list of features you need and what compilers you are using, I can try to focus my efforts. I'd imagine you'll be making heavy use of associated templates, which I don't have yet, and for the time being they will only be able to work in clang as that's the only compiler I know of that currently supports template aliasing. -- -Matt Calabrese

Gordon Woodhull

10:26 p.m.

On May 30, 2011, at 11:02 AM, Matt Calabrese wrote:

...

On Sun, May 29, 2011 at 7:00 PM, Gordon Woodhull wrote: (Hoping that Matt Calabrese's proposed Boost.Generic will be up and running later this year!)

If you have a list of features you need and what compilers you are using, I can try to focus my efforts. I'd imagine you'll be making heavy use of associated templates, which I don't have yet, and for the time being they will only be able to work in clang as that's the only compiler I know of that currently supports template aliasing.

Well, of course until I heard your talk I had planned to do without concepts because they didn't exist. But here is the problem I am trying to solve; perhaps you can tell me if this is possible. A system of objects at compile time is a graph of types and their relations. Where I am hoping concepts will help is to be able to define abstractly what sort of interfaces exist between these types, and then validate that the concrete implementation meets the concepts. So, I think this requires carrying concepts as metadata in the edges of a compile-time graph specified by the Metagraph user, and then traversing both the abstract and the concrete graphs validating the types against the concepts they are supposed to implement. Is this possible? Or am I thinking about the problem the wrong way? I am okay with clang-only for now since I'm only doing validation. I don't think I would try to use concept maps or archetypes in a first pass, although those will surely help in the long run. Thanks, Gordon

Gordon Woodhull

11:03 p.m.

On May 30, 2011, at 6:26 PM, Gordon Woodhull wrote:

...

So, I think this requires carrying concepts as metadata in the edges of a compile-time graph specified by the Metagraph user, and then traversing both the abstract and the concrete graphs validating the types against the concepts they are supposed to implement.

Gladly, the concepts don't need to be defined within the graph or generated from the graph (! generative concepts would get very confusing!), I just need to define them elsewhere and then refer to them within the graph. And I'm not sure how this would work, referring to a concept and embedding it as metadata without yet knowing what types it will apply to. Maybe it will in fact be easier with your simulation than with actual concepts, because we know how to carry metafunctions around. But I'm also curious to know whether it works with real concepts.

Matt Calabrese

31 May 31 May

12:10 a.m.

On Mon, May 30, 2011 at 7:03 PM, Gordon Woodhull wrote:

...

Gladly, the concepts don't need to be defined within the graph or generated from the graph (! generative concepts would get very confusing!), I just need to define them elsewhere and then refer to them within the graph. And I'm not sure how this would work, referring to a concept and embedding it as metadata without yet knowing what types it will apply to.

Maybe it will in fact be easier with your simulation than with actual concepts, because we know how to carry metafunctions around. But I'm also curious to know whether it works with real concepts.

Concepts, as they were proposed, could only appear at namespace scope, so you can't, for instance, have some kind of complex, metaprogrammed concept that is generated based on a compile-time graph from within a template. That would be very powerful, indeed, but is not possible. You also can't pass concepts themselves around as template parameters or alias them within types, so there technically isn't a way to store a concept as data in a compile-time graph. However, as you have said, since I am emulating concepts with templates, I could branch off from what concepts were and actually support such features, but I'd rather avoid that and stick as close to what would have been standard as I can, at least until I implement everything that would have been standard as well as I can. Perhaps once I finish that, I will consider experimenting with further functionality, but that is a ways off. -- -Matt Calabrese

Gordon Woodhull

1:15 a.m.

On May 30, 2011, at 8:00 PM, Matt Calabrese wrote:

...

Can you give an example of what kind of interface requirements you'd have? I'm imagining that you mean some kind of required metafunctions that are associated with the types, in which case I'm pretty sure that all you'd need past what I currently have implemented are associated templates, but I want to make sure we really are on the same page.

I think so. Heterogeneous graph concepts are just like any heterogeneous container concepts. The only place where it might get weird is that you can have (if I'm using the terminology correctly) cycles of associated types. E.g. a graph has vertices, which connect to edges, which potentially have pointers back to the graph. But I don't see why this would be a problem, either defining a concept per type or one for all of the types. On May 30, 2011, at 8:10 PM, Matt Calabrese wrote:

...

Concepts, as they were proposed, could only appear at namespace scope, so you can't, for instance, have some kind of complex, metaprogrammed concept that is generated based on a compile-time graph from within a template. That would be very powerful, indeed, but is not possible.

Thank goodness. If I started thinking about that, my brain would explode.

...

You also can't pass concepts themselves around as template parameters or alias them within types, so there technically isn't a way to store a concept as data in a compile-time graph.

Hmmmm. Is there even a way of mapping from a type to a concept, i.e. having tags that identify concepts? Or is the mapping strictly the other way around by design?

...

However, as you have said, since I am emulating concepts with templates, I could branch off from what concepts were and actually support such features, but I'd rather avoid that and stick as close to what would have been standard as I can, at least until I implement everything that would have been standard as well as I can. Perhaps once I finish that, I will consider experimenting with further functionality, but that is a ways off.

Well, I wouldn't want you to muddy your library with non-standard features. I was just figuring that as a (mis-)user I could pass the Generic concepts around since they're actually templates. But it kind of sounds like I'm trying to use concepts wrong. If I can't describe an abstract pattern in metadata, perhaps it is enough just to validate a concrete pattern using concepts. I was hoping to have a way to say "this algo requires a system of objects which model all of these concepts." Maybe I don't need to put the concepts in a graph in order to do that. I'll have to think about it more. Metagraphs are also a ways off. Thanks, Gordon

Matt Calabrese

midnight

On Mon, May 30, 2011 at 6:26 PM, Gordon Woodhull wrote:

...

A system of objects at compile time is a graph of types and their relations. Where I am hoping concepts will help is to be able to define abstractly what sort of interfaces exist between these types, and then validate that the concrete implementation meets the concepts.

Can you give an example of what kind of interface requirements you'd have? I'm imagining that you mean some kind of required metafunctions that are associated with the types, in which case I'm pretty sure that all you'd need past what I currently have implemented are associated templates, but I want to make sure we really are on the same page.

...

So, I think this requires carrying concepts as metadata in the edges of a compile-time graph specified by the Metagraph user, and then traversing both the abstract and the concrete graphs validating the types against the concepts they are supposed to implement.

That would not be possible, at least in terms of the 0x proposed concepts, though given your earlier description I'm not entirely convinced that you actually need such functionality to accomplish what you want. -- -Matt Calabrese

5016

Age (days ago)

5018

Last active (days ago)

List overview

Download

8 comments

4 participants

participants (4)

Gordon Woodhull
Matt Calabrese
Robert Ramey
Steven Watanabe