[GSoC, MPL11] Community probe
Dear Boost, As a follow-up to [1], I am probing the community to help clarify what are your needs/expectations with respect to a new TMP library. Your involvement is important as it will help direct my work on an eventual successor to the MPL (in consultation with my mentor, Joel Falcou). I expect this to be the first of a series of probes to the community. This one focuses on backward compatibility with the MPL. COMMUNITY PROBE --------------- Please comment on how you would like to see the following points addressed by a new TMP library: (1) Backward compatibility with the MPL. Should it be a swap-in replacement? Is it enough to have an easy way to interoperate between both libraries (think Fusion/MPL interoperation)?. (2) Learning curve for users coming from the MPL. How important is it for you to be able to reuse your knowledge of the MPL (not of TMP, but of the MPL itself)?. Please get involved by posting constructive material. Regards, Louis Dionne PS: As I expect this to be the first of a couple of community-wide probes, is there a preferred way to do these (on the ML or elsewhere)? PPS: If the thread gets very active, I might be slow to answer. I'm spread between this and my finals. [1]: http://article.gmane.org/gmane.comp.lib.boost.devel/250424
On 22 April 2014 15:09, Louis Dionne <ldionne.2@gmail.com> wrote:
Dear Boost,
As a follow-up to [1], I am probing the community to help clarify what are your needs/expectations with respect to a new TMP library. Your involvement is important as it will help direct my work on an eventual successor to the MPL (in consultation with my mentor, Joel Falcou).
Apologies if I'm a little late to the discussion, but could you summarize in few sentences to objective of the TMP library, particularly with respect to extending/enhancing/correcting the MPL? Thx. Rob.
On 22 April 2014 15:30, Robert Jones <robertgbjones@gmail.com> wrote:
Apologies if I'm a little late to the discussion, but could you summarize in few sentences to objective of the TMP library, particularly with respect to extending/enhancing/correcting the MPL?
Thx. Rob.
Ok, I've found the other post now, sorry for the noise.
On 4/22/2014 10:09 AM, Louis Dionne wrote:
Dear Boost,
As a follow-up to [1], I am probing the community to help clarify what are your needs/expectations with respect to a new TMP library. Your involvement is important as it will help direct my work on an eventual successor to the MPL (in consultation with my mentor, Joel Falcou).
I expect this to be the first of a series of probes to the community. This one focuses on backward compatibility with the MPL.
COMMUNITY PROBE --------------- Please comment on how you would like to see the following points addressed by a new TMP library:
(1) Backward compatibility with the MPL. Should it be a swap-in replacement? Is it enough to have an easy way to interoperate between both libraries (think Fusion/MPL interoperation)?.
I do not think you must strive for perfect backward compatibility. But if you can provide an easy interoperation in as many places as possible that would be helpful. In particular, however, do not change a better design, when you have one, just to provide a means of backward compatibility.
(2) Learning curve for users coming from the MPL. How important is it for you to be able to reuse your knowledge of the MPL (not of TMP, but of the MPL itself)?.
If one understands the MPL ( no easy initial task ) it should be fairly easy to understand whatever your library's different idioms might be. So I do not think you should worry about the learning curve but rather just document your library as thoroughly as possible. At the level of the MPL, and template metaprogramming in general, a C++ programmer has to be good enough technically that he will understand your library if it is documented well. Whatever is not understood will be asked about when your library is reviewed, and that feedback will enable you to improve any documentation which may be found wanting.
Le 22/04/14 16:09, Louis Dionne a écrit :
Dear Boost,
As a follow-up to [1], I am probing the community to help clarify what are your needs/expectations with respect to a new TMP library. Your involvement is important as it will help direct my work on an eventual successor to the MPL (in consultation with my mentor, Joel Falcou).
I expect this to be the first of a series of probes to the community. This one focuses on backward compatibility with the MPL.
COMMUNITY PROBE --------------- Please comment on how you would like to see the following points addressed by a new TMP library:
(1) Backward compatibility with the MPL. Should it be a swap-in replacement? Is it enough to have an easy way to interoperate between both libraries (think Fusion/MPL interoperation)?.
(2) Learning curve for users coming from the MPL. How important is it for you to be able to reuse your knowledge of the MPL (not of TMP, but of the MPL itself)?.
Please get involved by posting constructive material.
Hi, I'm not concerned with MPL-backward compatibility or the learning curve for users coming from MPL. You have an opportunity to build a new TMP library, the work will be long and hard, but adding more constraints than needed wouldn't help. TMP should be a basic library and other inter-operable libraries must be build on top of it. Of course, the new TMP should perform better and be easier to learn than MPL. This must be possible as C++14 provides more features and so you will be able to choose the ones that go towards this goal. What I would like is something that can be proposed to the C++ standard. A little bit more of TMP in the standard would be much better than much more in Boost but outside the C++ standard. Best, Vicente
Le 22/04/14 16:09, Louis Dionne a écrit :
Dear Boost,
As a follow-up to [1], I am probing the community to help clarify what are your needs/expectations with respect to a new TMP library. Your involvement is important as it will help direct my work on an eventual successor to the MPL (in consultation with my mentor, Joel Falcou).
I expect this to be the first of a series of probes to the community. This one focuses on backward compatibility with the MPL.
COMMUNITY PROBE --------------- Please comment on how you would like to see the following points addressed by a new TMP library:
(1) Backward compatibility with the MPL. Should it be a swap-in replacement? Is it enough to have an easy way to interoperate between both libraries (think Fusion/MPL interoperation)?.
(2) Learning curve for users coming from the MPL. How important is it for you to be able to reuse your knowledge of the MPL (not of TMP, but of the MPL itself)?.
Please get involved by posting constructive material.
Hi,
I'm not concerned with MPL-backward compatibility or the learning curve for users coming from MPL. You have an opportunity to build a new TMP library, the work will be long and hard, but adding more constraints than needed wouldn't help. TMP should be a basic library and other inter-operable libraries must be build on top of it.
Of course, the new TMP should perform better and be easier to learn than MPL. This must be possible as C++14 provides more features and so you will be able to choose the ones that go towards this goal.
What I would like is something that can be proposed to the C++ standard. A little bit more of TMP in the standard would be much better than much more in Boost but outside the C++ standard. I agree completely. I recently developed my own type set since I could not use MPL (no full variadicity) or the standard library (no type set). And even though it was kind of fun to implement, I would have preferred to use something from the standard (or from something aiming to become
On 2014-04-22 23:33, Vicente J. Botet Escriba wrote: the standard). That being said, I think you should aim for TMP14. Personally I would very much consider C++14 plus Concepts Lite, because you are building a library for the future, not for the past. Best regards, Roland
Roland Bock <rbock <at> eudoxos.de> writes:
I agree completely. I recently developed my own type set since I could not use MPL (no full variadicity) or the standard library (no type set). And even though it was kind of fun to implement, I would have preferred to use something from the standard (or from something aiming to become the standard).
By any chance, would the type set implementation happen to be public? I know of a couple different ways to implement those, but it's always good to see what others have done.
That being said, I think you should aim for TMP14. Personally I would very much consider C++14 plus Concepts Lite, because you are building a library for the future, not for the past.
As I currently view things, C++14 won't be such a game changer wrt TMP, but I must look into Concepts Lite more seriously before that's definitive. See my answer to Gonzalo for more on that. TYVM for your input, Louis
Could you please expand on the nature of metaprogramming you have been doing with constexpr? Are you talking about manipulating values of a literal type, or about "pure type" computations?
It has been mostly about manipulating values of a literal type and tuples. I'm still new to these kind of situations but I can see myself in the future preferring to use a std::tuple as a type vector (ignoring the values) and performing transformations inside a constexpr function using a Boost.Fusion-like library and then just decltype the result to get the type. Relaxed constexpr and automatic type deduction for normal functions makes this approach straightforward. To get the point across, this is how the machinery and the usage _could_ look like: /// Quote: template<template <class> class U> struct quote { template<class T> auto operator()(T&&) { return U<T>{}; } }; /// Your complex transform function: template<class Tuple> constexpr auto my_transform(Tuple&&) { // note: Fusion is not annotated with constexpr yet auto tmp = boost::fusion::transform(Tuple{}, quote<std::add_pointer_t>{}); return boost::fusion::transform(tmp, quote<std::add_reference_t>{}); } /// Usage: using ref_to_pointers = decltype(my_transform(std::tuple<int, char, void, my_own_type>{})); This approach has advantages/disadvantages, the ones that come to mind are: - i think it only works if the types in the tuple have constexpr constructors (_huge drawback_ unless a workaround is found), - performance (it might be slower to compile, but I haven't profiled so I don't know), - it gives you a unified way of performing type-only and type-value manipulations at compile-time, - it might be easier to explain to beginners since it is more imperative and has less templates, - you cannot use lambda functions inside relaxed-constexpr functions (so the restricted part of C++ that is allowed inside constexpr functions needs to be considered). I'm not proposing this as a good way to do metaprogramming. I've just found that this way is useful in some situations and I think it is worth exploring to get a better idea of its advantages/disadvantages.
"What is the purpose of a TMP library?"
This is a very good question. Is the compile-time reflection offered by Boost.Fusion metaprogramming? If so, Boost.MPL and Boost.Fusion would have some overlap that might be worth studying.
I hope this answers your questions; sorry for the long-winded answer but I think it can be informative for others too.
Thanks for the answer, you are doing a great job! Bests, Gonzalo On Tue, Apr 29, 2014 at 11:42 PM, Louis Dionne <ldionne.2@gmail.com> wrote:
Roland Bock <rbock <at> eudoxos.de> writes:
I agree completely. I recently developed my own type set since I could not use MPL (no full variadicity) or the standard library (no type set). And even though it was kind of fun to implement, I would have preferred to use something from the standard (or from something aiming to become the standard).
By any chance, would the type set implementation happen to be public? I know of a couple different ways to implement those, but it's always good to see what others have done.
That being said, I think you should aim for TMP14. Personally I would very much consider C++14 plus Concepts Lite, because you are building a library for the future, not for the past.
As I currently view things, C++14 won't be such a game changer wrt TMP, but I must look into Concepts Lite more seriously before that's definitive. See my answer to Gonzalo for more on that.
TYVM for your input, Louis
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Dipl.-Ing. Gonzalo Brito Gadeschi Institute of Aerodynamics and Chair of Fluid Mechanics RWTH Aachen University Wuellnerstraße 5a D-52062 Aachen Germany Phone: ++49-(0)241-80-94821 Fax: ++49-(0)241-80-92257 E-mail: g.brito@aia.rwth-aachen.de Internet: www.aia.rwth-aachen.de
Gonzalo Brito Gadeschi <g.brito <at> aia.rwth-aachen.de> writes:
This approach has advantages/disadvantages, the ones that come to mind are: - i think it only works if the types in the tuple have constexpr constructors (_huge drawback_ unless a workaround is found),
I think it won't work with incomplete types, with types that don't have a default constructor and with function types too. There might be a good workaround for this though.
- performance (it might be slower to compile, but I haven't profiled so I don't know),
If it turns out to be an interesting avenue, I'll benchmark it properly.
- it gives you a unified way of performing type-only and type-value manipulations at compile-time,
Definitely a plus.
- you cannot use lambda functions inside relaxed-constexpr functions (so the restricted part of C++ that is allowed inside constexpr functions needs to be considered).
Another thing with constexpr functions is that you can't static_assert on their arguments, but I don't think that would be a show stopper.
If so, Boost.MPL and Boost.Fusion would have some overlap that might be worth studying.
I do think these libraries overlap. Actually, I think Fusion would be pretty much a superset of the MPL if it was not for the fact that Fusion must work with types that can be constructed. Could someone involved with Fusion confirm or refute this? Regards, Louis
On 2014-04-29 23:42, Louis Dionne wrote:
Roland Bock <rbock <at> eudoxos.de> writes:
I agree completely. I recently developed my own type set since I could not use MPL (no full variadicity) or the standard library (no type set). And even though it was kind of fun to implement, I would have preferred to use something from the standard (or from something aiming to become the standard). By any chance, would the type set implementation happen to be public? I know of a couple different ways to implement those, but it's always good to see what others have done. The type set is part of sqlpp11: https://github.com/rbock/sqlpp11/blob/master/include/sqlpp11/detail/type_set...
It is a bit messy right now, but the basic idea should be obvious. Please let me know if you have questions.
That being said, I think you should aim for TMP14. Personally I would very much consider C++14 plus Concepts Lite, because you are building a library for the future, not for the past. As I currently view things, C++14 won't be such a game changer wrt TMP, but I must look into Concepts Lite more seriously before that's definitive. See my answer to Gonzalo for more on that.
In my view, C++14 will not change what can be done, but return type reduction and possibly tuple addressing via type will reduce the amount of code I need to write. And Concepts Lite will have a tremendous impact on sqlpp11 in terms of error messages generated by the compiler and the amount of code. Thus, before I try to get sqlpp11 into boost, I will rewrite it for C++14 and Concepts Lite (and rename it ;-) ). Otherwise I would have to carry on with too much code and too long error message way too long, I believe.
TYVM for your input, Louis
:-) Regards, Roland
Roland Bock <rbock <at> eudoxos.de> writes:
The type set is part of sqlpp11: https://github.com/rbock/sqlpp11/blob/master/include/sqlpp11/detail/type_set...
It is a bit messy right now, but the basic idea should be obvious. Please let me know if you have questions.
Thanks a lot! The type set implementation is nice; I had not thought about that way to do it. If you don't mind, would like to add an implementation inspired by yours to the set of techniques I'm benchmarking for the MPL11. Of course, I will give you proper credits. As an aside, I think your `all_t` and `any_t` metafunctions could be more efficient. I'm currently (literally right now) benchmarking different implementations for those; I will notify you if there is a better alternative. Regards, Louis
On 30/04/2014 07:34 p.m., Louis Dionne wrote:
As an aside, I think your `all_t` and `any_t` metafunctions could be more efficient. I'm currently (literally right now) benchmarking different implementations for those; I will notify you if there is a better alternative.
I don't know which implementations you are considering (are they publicly available online?), but here is one I found to perform good enough: https://github.com/eggs-cpp/tupleware/blob/draft/include/eggs/tupleware/core... Just drop the `constexpr` since it's not actually needed and it confuses GCC. It's a bug according to my reading of [expr.unary.noexcept]/3, but I didn't have the time to investigate further yet. Regard, -- Agustín K-ballo Bergé.- http://talesofcpp.fusionfenix.com
On 2014-05-01 05:10, Agustín K-ballo Bergé wrote:
On 30/04/2014 07:34 p.m., Louis Dionne wrote:
As an aside, I think your `all_t` and `any_t` metafunctions could be more efficient. I'm currently (literally right now) benchmarking different implementations for those; I will notify you if there is a better alternative.
I don't know which implementations you are considering (are they publicly available online?), but here is one I found to perform good enough:
https://github.com/eggs-cpp/tupleware/blob/draft/include/eggs/tupleware/core...
Just drop the `constexpr` since it's not actually needed and it confuses GCC. It's a bug according to my reading of [expr.unary.noexcept]/3, but I didn't have the time to investigate further yet.
Regard, Very cool, indeed. The only drawback in my eyes is that the logic of using noexcept is a bit convoluted.
That got me thinking, and here's a new version. Even faster (at least on my setup, see below), and very easy to read, I think: // ------------------------------ #include <type_traits> template<bool...> struct all_helper {}; template<bool... Bs> using all_t = std::is_same<all_helper<Bs...>, all_helper<(true or Bs)...>>; // -------------------------------- I am going to use that in sqlpp11 for the time being, see https://github.com/rbock/sqlpp11/blob/develop/include/sqlpp11/detail/logic.h Here are some adhoc measurements, using a static_assert with 65536 true bool arguments (reduced code is attached): clang++-3.2 -std=c++11 -stdlib=libc++: Roland: 0.27s Agustín: 0.73s clang++-3.4.1 -std=c++11 -stdlib=libc++: Roland: 0.30s Agustín: crashes on my machine g++-4.8 -std=c++11: Roland: 0.28s Agustín: 0.79s Adding a false at the end (asserting a false value) yields the same numbers. Thanks and best regards, Roland
On 01/05/2014 09:13 a.m., Roland Bock wrote:
On 2014-05-01 05:10, Agustín K-ballo Bergé wrote:
On 30/04/2014 07:34 p.m., Louis Dionne wrote:
As an aside, I think your `all_t` and `any_t` metafunctions could be more efficient. I'm currently (literally right now) benchmarking different implementations for those; I will notify you if there is a better alternative.
I don't know which implementations you are considering (are they publicly available online?), but here is one I found to perform good enough:
https://github.com/eggs-cpp/tupleware/blob/draft/include/eggs/tupleware/core...
Very cool, indeed. The only drawback in my eyes is that the logic of using noexcept is a bit convoluted.
That got me thinking, and here's a new version. Even faster (at least on my setup, see below), and very easy to read, I think:
// ------------------------------ #include <type_traits>
template<bool...> struct all_helper {};
template<bool... Bs> using all_t = std::is_same<all_helper<Bs...>, all_helper<(true or Bs)...>>; // --------------------------------
Awesome results, and the technique is so simple! I'm going to keep this approach in mind for other possible use cases in the future. Regards, -- Agustín K-ballo Bergé.- http://talesofcpp.fusionfenix.com
Roland Bock <rbock <at> eudoxos.de> writes: [...]
That got me thinking, and here's a new version. Even faster (at least on my setup, see below), and very easy to read, I think:
// ------------------------------ #include <type_traits>
template<bool...> struct all_helper {};
template<bool... Bs> using all_t = std::is_same<all_helper<Bs...>, all_helper<(true or Bs)...>>; // --------------------------------
This is _awesome_; thank you for sharing. According to my benchmarks (see my reply to Augustin), that is the most efficient way of performing a non short circuiting logical and at compile-time on <= 1K booleans. Louis
Louis Dionne <ldionne.2 <at> gmail.com> writes: [...]
This is _awesome_; thank you for sharing. According to my benchmarks (see my reply to Augustin), that is the most efficient way of performing a non short circuiting logical and at compile-time on <= 1K booleans.
Apologies for misnaming Agustín. Louis
On 2014-05-03 20:41, Louis Dionne wrote:
Roland Bock <rbock <at> eudoxos.de> writes:
[...]
That got me thinking, and here's a new version. Even faster (at least on my setup, see below), and very easy to read, I think:
// ------------------------------ #include <type_traits>
template<bool...> struct all_helper {};
template<bool... Bs> using all_t = std::is_same<all_helper<Bs...>, all_helper<(true or Bs)...>>; // -------------------------------- This is _awesome_; thank you for sharing. According to my benchmarks (see my reply to Augustin), that is the most efficient way of performing a non short circuiting logical and at compile-time on <= 1K booleans.
Louis
You're welcome, thanks a lot for the credits!
Agustín K-ballo Bergé <kaballo86 <at> hotmail.com> writes:
On 30/04/2014 07:34 p.m., Louis Dionne wrote:
As an aside, I think your `all_t` and `any_t` metafunctions could be more efficient. I'm currently (literally right now) benchmarking different implementations for those; I will notify you if there is a better alternative.
I don't know which implementations you are considering (are they publicly available online?), but here is one I found to perform good enough:
[...] I have been gathering different techniques over the past months. They are available here: http://goo.gl/D0kA7C The associated benchmarks are here: http://goo.gl/swNEhA Datasets are sometimes messed up, but removing extreme values and changing the plot scale makes the graphs more informative. Since this is material for my C++Now presentation, I'd rather keep it low for now. Regards, Louis
On 2014-05-01 00:34, Louis Dionne wrote:
Roland Bock <rbock <at> eudoxos.de> writes:
The type set is part of sqlpp11: https://github.com/rbock/sqlpp11/blob/master/include/sqlpp11/detail/type_set...
It is a bit messy right now, but the basic idea should be obvious. Please let me know if you have questions. Thanks a lot! The type set implementation is nice; I had not thought about that way to do it. If you don't mind, would like to add an implementation inspired by yours to the set of techniques I'm benchmarking for the MPL11. Of course, I will give you proper credits. Sure, I appreciate that!
If you're looking for other ways, I also had an older one, which I thought just had to be faster (using multiple inheritance and is_base_of), but at least for my purposes it did not make a difference: https://github.com/rbock/sqlpp11/blob/0.8/include/sqlpp11/detail/set.h I'd be interested in how that implementation performs in your tests, too :-)
As an aside, I think your `all_t` and `any_t` metafunctions could be more efficient. I'm currently (literally right now) benchmarking different implementations for those; I will notify you if there is a better alternative.
Looking forward to that :-) Thanks and regards, Roland
Roland Bock <rbock <at> eudoxos.de> writes: [...]
If you're looking for other ways, I also had an older one, which I thought just had to be faster (using multiple inheritance and is_base_of), but at least for my purposes it did not make a difference:
https://github.com/rbock/sqlpp11/blob/0.8/include/sqlpp11/detail/set.h
I'd be interested in how that implementation performs in your tests, too
Thanks for sharing. I am working on something else right now, but I will check it out in depth when I dive into associative sequences again. I should be able to provide benchmarks in (or before) Aspen. Regards, Louis
On 22 Apr 2014 at 23:33, Vicente J. Botet Escriba wrote:
I'm not concerned with MPL-backward compatibility or the learning curve for users coming from MPL. You have an opportunity to build a new TMP library, the work will be long and hard, but adding more constraints than needed wouldn't help. TMP should be a basic library and other inter-operable libraries must be build on top of it.
Of course, the new TMP should perform better and be easier to learn than MPL. This must be possible as C++14 provides more features and so you will be able to choose the ones that go towards this goal.
What I would like is something that can be proposed to the C++ standard. A little bit more of TMP in the standard would be much better than much more in Boost but outside the C++ standard.
+1 on Vicente's opinion. I see no problem with your current plan Louis, and besides everyone here is a backseat driver and doesn't really have the domain experience that you do. I'd present on the options you've discovered so far at C++ Now as you're already doing, and listen to Joel's opinion, he's very experienced on the topic, and I'm sure he'll make sure you go the right way. Maybe this time next year once you have the TMP14 engine in place and well tested, then would be the time to think about MPL98 compatibility and all that jazz as a second GSoC. Between now and then you'll need to decide on Concepts, sadly Andrew won't be at C++ Now this year as he's the right person to talk to, but I may try to very poorly fill Andrew's place and talk to you myself after your talk. Niall -- Currently unemployed and looking for work in Ireland. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
I have a question: the proposal and library are called MPL11. In my experience, relaxed constexpr allows for beautiful metaprogramming with respect to C++11, in particular when combined with Boost.Fusion, and I think that it is really a game changer with respect to C++11 constexpr, since it allows not only "functional" metaprogramming but also "imperative" metaprogramming, significantly lowering the learning curve of metaprogramming for C++ programmers. Have you consider the influence of relaxed constexpr (C++14) in your library? Could it simplify the design/implementation/usage of the MPL? Would a rewrite of MPL11 be necessary afterwards (MPL14)? On Wed, Apr 23, 2014 at 11:51 AM, Niall Douglas <s_sourceforge@nedprod.com>wrote:
On 22 Apr 2014 at 23:33, Vicente J. Botet Escriba wrote:
I'm not concerned with MPL-backward compatibility or the learning curve for users coming from MPL. You have an opportunity to build a new TMP library, the work will be long and hard, but adding more constraints than needed wouldn't help. TMP should be a basic library and other inter-operable libraries must be build on top of it.
Of course, the new TMP should perform better and be easier to learn than MPL. This must be possible as C++14 provides more features and so you will be able to choose the ones that go towards this goal.
What I would like is something that can be proposed to the C++ standard. A little bit more of TMP in the standard would be much better than much more in Boost but outside the C++ standard.
+1 on Vicente's opinion. I see no problem with your current plan Louis, and besides everyone here is a backseat driver and doesn't really have the domain experience that you do. I'd present on the options you've discovered so far at C++ Now as you're already doing, and listen to Joel's opinion, he's very experienced on the topic, and I'm sure he'll make sure you go the right way.
Maybe this time next year once you have the TMP14 engine in place and well tested, then would be the time to think about MPL98 compatibility and all that jazz as a second GSoC. Between now and then you'll need to decide on Concepts, sadly Andrew won't be at C++ Now this year as he's the right person to talk to, but I may try to very poorly fill Andrew's place and talk to you myself after your talk.
Niall
-- Currently unemployed and looking for work in Ireland. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Dipl.-Ing. Gonzalo Brito Gadeschi Institute of Aerodynamics and Chair of Fluid Mechanics RWTH Aachen University Wuellnerstraße 5a D-52062 Aachen Germany Phone: ++49-(0)241-80-94821 Fax: ++49-(0)241-80-92257 E-mail: g.brito@aia.rwth-aachen.de Internet: www.aia.rwth-aachen.de
participants (8)
-
Agustín K-ballo Bergé -
Edward Diener -
Gonzalo Brito Gadeschi -
Louis Dionne -
Niall Douglas -
Robert Jones -
Roland Bock -
Vicente J. Botet Escriba