Re: [boost] Boost.Hana - Type Classes, data types and categories (tags).

Subject: Re: [boost] Boost.Hana - Type Classes, data types and categories (tags).
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2014-09-23 07:17:45

On 20 Sep 2014 at 15:03, Louis Dionne wrote:

> > > I had not thought about the issue because right now, name clashing is
> > > avoided simply by not having two functions with the same name. This has
> > > worked well so far. Since this is the simplest way to do things, I'd
> > > rather keep it that way. Of course, if I need to introduce a function
> > > whose name would clash, then I will strongly consider your suggestion;
> > > thank you for that. 
> > 
> > namespaces can be used for disambiguation, but they are actually much 
> > more useful and powerful than that. You can map namespaces into other 
> > namespaces, mash up namespaces into customised variants and with 
> > template aliasing you can now easily metaprogram namespacing too, so 
> > you could have the results of a Hana operation cause one set of 
> > things to be mapped into some destination namespace as against 
> > another set of things. And then, you see, a bind() function can 
> > actually have metaprogrammed meaning and implementation which is not 
> > only neato, but very intuitive for the end user.
> 
> I'm not sure I understand you. I do understand how we can map namespaces into 
> other namespaces:
>     
>     namespace A { }
>     namespace B = A;
> 
> I also understand how we can mash up namespaces:
>     
>     namespace A { }
>     namespace B { }
>     namespace mash {
>         using namespace A;
>         using namespace B;
>     }
> 
> But I don't understand how template aliases come into play and give me more
> flexibility. Would you care to give a basic example of what you meant?

The way I look at it is this: templated types are templated 
namespaces with restrictions on what you can put in them (aside: I 
have never understood why you can't template namespaces and use 
namespaces for inheritance, including types and other namespaces), 
while namespaces let you draw arbitrary lines around segments of API 
and mux them as appropriate into different default visibility 
according to point of use.

Let us take an example:

namespace A
{
  template<class T> using vector = select_vector_impl<A_scope, T>;
}
namespace B
{
  template<class T> using vector = select_vector_impl<B_scope, T>;
}
namespace C
{
  // I specifically say I use the same vector as namespace B
  template<class T> using B::vector<T>;
}

The annoying thing with the present C++ syntax is that for every type 
item you wish to mash up you need a separate chain of namespace using 
going into some specialised type which then jumps through 
metaprogramming to map the type. This is tedious, but I would assume 
that something like Edward's VMD library ought to allow automation of 
the generation of these chains such that one could then simply write:

namespace A
{
  USING_STL_IMPL(A);
  // unordered_map => std::unordered_map etc
}
namespace B
{
  USING_STL_IMPL(B);
  // unordered_map => boost::unordered_map etc
}

This might not look like it conveys much utility on its own. But 
imagine if you were handed a large lump of library code and you are 
not allowed to touch or modify it, but it has several bugs and 
problems, and your client code needs to work around them.

If the original library hard codes that namespace A uses the STL and 
namespace B uses boost, your hands are tied and you probably will 
have to write a clang AST parser to bind the original library into a 
duplicate, but fixed copy of its namespace. If instead tag based 
symbol binding is used, you can partially specialise the template 
programming sitting in between the namespace bind and its 
implementation, and thus your library becomes much more easier for 
others to mash up and mess around with from the outside.

All this said, is it worth the programmer manually doing these binds 
when a clang AST tool could grok the original and generate a 
metaprogrammed bound but otherwise identical duplicate? That I 
currently don't know the answer to. If a clang AST tool can do so, 
forget I ever wrote this email or raised this topic, as it is moot.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/