Re: langbinding questions

[Dave Abrahams]

Hi Jim,

Sorry this is so late.  Sick, work, sick, work... you know how it can
be.

on Sun Jan 15 2012, Jim Bosch <talljimbo-AT-gmail.com> wrote:

> I've been trying to wrap my head around some Boost.Langbinding
> concepts as part of my (slow, but not dead) work on an eventual
> Boost.Python v3. I've got some questions - and if there are others who
> I should be sending this email to, please let me know and/or forward.

Yeah, you should send it to the langbinding list and/or Cc: Daniel
Wallin.

> As I understand it, the basic idea is:
>
> 1) We build a language-agnostic front-end "module definition" data
> structure that gets stored in a static object.

I don't know what you mean by "static object," but the rest is dead on.

> 2) That data structure hides all the type information somehow

Hides it at compile-time; represents it at runtime.

> - I'm imagining a polymorphic non-template base class with templated
> derived classes, or something equivalent.  But I get the sense that
> this may be an incorrect assumption.

I don't know why; sounds like a classic type erasure pattern.

> 3) We pass in a target-language-specific "module builder" to the
> "module definition", which goes through itself and calls visit member
> functions on the "module builder", which in turn creates the
> target-language wrapper.

That sounds right.

> I can see, roughly, how this would work if there's only one module
> builder class (i.e. one target language).  The polymorphic classes in
> the module definition would have virtual functions that just take a
> module_builder instance, and then they can call templated visit member
> functions on the module_builder.
>
> But I don't think that model is what was intended - it doesn't scale
> well to multiple target languages,

In what way?

> and it doesn't explain why the module_builder classes in the proposal
> (I'm looking here: http://www.boostpro.com/writing/oopsla04.html) use
> CRTP.

I don't see any CRTP.  There's some prototype code in SVN that might explain
details such as module_builder's template parameter.

> I'm also confused (probably in a related way) about the type of the
> arguments to the module_builder::visit functions; somebody has to do
> the target-language specific dirty work of creating a wrapped
> backend::function<B> from an arbitrary C++ function pointer or other
> callable, and I would have expected that to be a job for the
> module_builder, not the front-end element that is calling
> module_builder::visit.

yep.  Seems like a bug in that doc.  I expect the module_builder to
visit frontend:: thangs.  Maybe, though, I had the idea that things in
the backend:: namespace should encompass everything the backend has to
process.  It's clearly not templatized on the backend language and
therefore not specific to the back-end at all.

> Note that I'm not trying to implement all of Boost.Langbinding, or
> even most - I'm just trying to understand it so I can write a more
> future-friendly Boost.Python.

Thanks for asking, Jim.

--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Boost-langbinding mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/boost-langbinding

[Jim Bosch-2]

Thanks...it sounds like I understand things better than I thought I did.
  Though I'm still worried that I'm confusing which is the "accept" and
which is the "visit" class somehow.  More questions/replies below.

>> As I understand it, the basic idea is:
>>
>> 1) We build a language-agnostic front-end "module definition" data
>> structure that gets stored in a static object.
>
> I don't know what you mean by "static object," but the rest is dead on.
>

I just meant a namespace-scope variable, static data member, or static
function-scope variable.  Is there a good catch-all term for such variables?

>> I can see, roughly, how this would work if there's only one module
>> builder class (i.e. one target language).  The polymorphic classes in
>> the module definition would have virtual functions that just take a
>> module_builder instance, and then they can call templated visit member
>> functions on the module_builder.
>>
>> But I don't think that model is what was intended - it doesn't scale
>> well to multiple target languages,
>
> In what way?
>

In the sense that all the frontend classes seem to need to enumerate all
the possible backends, because they each have a different module_builder
class.  Some super-simplified code for what I'm imagining:

class frontend_function {
public:
   virtual visit(python_builder & b) = 0;
   virtual visit(lua_builder & b) = 0;
};

template <typename FunctionPointer>
class frontend_function_t : public frontend_function {
public:
   virtual visit(python_builder & b) {
     b.wrap_function(m_name, m_func);
   }
   virtual visit(lua_builder & b) {
     b.wrap_function(m_name, m_func);
   }
private:
   std::string m_name;
   FunctionPointer m_func;
};

class python_builder : public module_builder {
public:
   template <typename FunctionPointer>
   void wrap_function(std::string const & name, FunctionPointer p);
};

This isn't horrible, and "doesn't scale" is the wrong phrase, but it
doesn't allow you to add new backends without modifying the core
library, and I had (perhaps naively) assumed that was part of the design.

>> and it doesn't explain why the module_builder classes in the proposal
>> (I'm looking here: http://www.boostpro.com/writing/oopsla04.html) use
>> CRTP.
>
> I don't see any CRTP.  There's some prototype code in SVN that might explain
> details such as module_builder's template parameter.
>

It's probably just a red-herring of some sort, but the section 3.2 of
the above doc starts with "Module builders must be instances of a class
derived from a CRTP base class".  I've looked at the langbinding code in
the boost svn sandbox, and I'm it seem to be mostly utility code at the
moment (though I admit I don't understand how a lot of it fits together,
so maybe I'm missing the forrest for the trees).

Thanks!

Jim


------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Boost-langbinding mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/boost-langbinding