DSEL syntax, or opening the can of worms.

DSEL syntax, or opening the can of worms.

First I think we all agree that the Luabind DSEL syntax is "nicer" than
the BPL syntax. Last night, something kept bothering me. The syntax
dealing with namespaces/modules vs. the syntax for dealing with classes
and inner classes are inconsistent with each other. Yet to me both deal
with defining scopes, and members within those scopes. To take a simple
example:

That shows that 'module' and 'namespace_' use [] to bound the scope they
define. But 'class' uses ".method" to chain the scope out as needed. And
introduces the rather unintuitive, IMO, '.scope' to allow one "access"
to the class scope. So I though, why not be consistent and use [] to
define all scopes. Which leads to (removing the module/namespace
destinction):

I guess that this was one the goals of the library. lang-binding is a
little bit different: it aims to provide different "back-ends". I
think it is impossible to come with a DSL, which will satisfy all
"back-end" developers and you are right: we should stick to one-to-one
correspondence with the C++ code.

Re: DSEL syntax, or opening the can of worms.

> namespace_(L,"a")
> [
> def("f",&a::f),
> class_<a::A>("A")
> [
> def("do",&a::A::do),
> class_<a::A::B>("B")
> [
> def("again",&a::A::B::again)
> ]
> ]
> ]
>
> Which has a one-to-one correspondence with the C++ code. So... Was this
> ever considered? If it was, why was it not used? Is there a discussion
> in the list I haven't read about this?

Yes. This was considered and dismissed at one point. The problem is that
you loose access to the class type in your def() calls. It's of course
possible to build an expression template out of the whole thing and
lazily evaluate it, but that would make compile time performance even worse.

It's possible that this performance degradation wouldn't matter that
much in practice, but there are other concerns as well. Off the top of
my head; any compilation problem that happens inside a def() call will
get delayed and happen deeper down in the call stack, since we'd need to
recursively evaluate the expression tree.

Re: DSEL syntax, or opening the can of worms.

> namespace_(L,"a")
> [
> def("f",&a::f),
> class_<a::A>("A")
> [
> def("do",&a::A::do),
> class_<a::A::B>("B")
> [
> def("again",&a::A::B::again)
> ]
> ]
> ]
>
> Which has a one-to-one correspondence with the C++ code. So... Was this
> ever considered? If it was, why was it not used? Is there a discussion
> in the list I haven't read about this?

I don't think it was ever discussed; I've been over the history at least
twice now, and I don't believe that the DSEL was discussed to this
extent. I think that only minor details were covered. I could have
missed something, though. There isn't any code to cover the frontend
either, so it seems that the DSEL is open territory for discussion.

Just a peanut gallery comment: I like Rene's proposed syntax better.
Ostensibly, you should be able just to drop a class into another class'
scope (though there may be details that would cause some difficulty that
I haven't thought of). It's also a lot smoother and, to me at least,
more expressive.

Re: DSEL syntax, or opening the can of worms.

> Rene Rivera wrote:
> [...]
>> namespace_(L,"a")
>> [
>> def("f",&a::f),
>> class_<a::A>("A")
>> [
>> def("do",&a::A::do),
>> class_<a::A::B>("B")
>> [
>> def("again",&a::A::B::again)
>> ]
>> ]
>> ]
>>
>> Which has a one-to-one correspondence with the C++ code. So... Was this
>> ever considered? If it was, why was it not used? Is there a discussion
>> in the list I haven't read about this?
>
> Yes. This was considered and dismissed at one point. The problem is that
> you loose access to the class type in your def() calls. It's of course
> possible to build an expression template out of the whole thing and
> lazily evaluate it, but that would make compile time performance even worse.

Of course I scrolled right to it after reading this. That's the thread
started by A. Nasonov, right?

> It's possible that this performance degradation wouldn't matter that
> much in practice, but there are other concerns as well. Off the top of
> my head; any compilation problem that happens inside a def() call will
> get delayed and happen deeper down in the call stack, since we'd need to
> recursively evaluate the expression tree.

Is that true? We wouldn't necessarily need to build "()" into the DSEL;
it could be left to be evaluated normally, thus allowing compilation to
catch bad def() calls at the point of use.

Re: DSEL syntax, or opening the can of worms.

John Moeller wrote:
> Daniel Wallin wrote:
>> Rene Rivera wrote:
[...]
>> Yes. This was considered and dismissed at one point. The problem is that
>> you loose access to the class type in your def() calls. It's of course
>> possible to build an expression template out of the whole thing and
>> lazily evaluate it, but that would make compile time performance even worse.
>
> Of course I scrolled right to it after reading this. That's the thread
> started by A. Nasonov, right?

I think so.

>> It's possible that this performance degradation wouldn't matter that
>> much in practice, but there are other concerns as well. Off the top of
>> my head; any compilation problem that happens inside a def() call will
>> get delayed and happen deeper down in the call stack, since we'd need to
>> recursively evaluate the expression tree.
>
> Is that true? We wouldn't necessarily need to build "()" into the DSEL;
> it could be left to be evaluated normally, thus allowing compilation to
> catch bad def() calls at the point of use.

Sorry, I don't understand. My point is that in:

class_<X>() [
def(..., &X::f); #1
]

#1 needs access to `X` from the enclosing class_<>. To do this we'd need
to delay the instantiation so that it happens inside
`class_<>::operator[]`, where `X` is known.

It was, though it may have been a private thing between me and Daniel.

> I've been over the history at least twice now, and I don't believe
> that the DSEL was discussed to this extent. I think that only minor
> details were covered. I could have missed something, though. There
> isn't any code to cover the frontend either, so it seems that the
> DSEL is open territory for discussion.
>
> Just a peanut gallery comment: I like Rene's proposed syntax
> better.

But as Daniel points out, there are some practical disadvantages.

> Ostensibly, you should be able just to drop a class into another
> class' scope (though there may be details that would cause some
> difficulty that I haven't thought of). It's also a lot smoother
> and, to me at least, more expressive.

Yeah, maybe... but this issue (and the one about explicit overload
selection, are really minor details that should have little impact on
the overall plan.

Right. It may not be entirely obvious why at first, but if you look
at the Boost.Python code that handles this, you'll see it. X::f might
actually be declared in a (non-exposed) base class of X, in which case
the type of its address doesn't actually have any way to deduce X at
all.

Re: DSEL syntax, or opening the can of worms.

David Abrahams wrote:

> on Wed Aug 08 2007, Daniel Wallin <daniel-AT-boost-consulting.com> wrote:
>
>> My point is that in:
>>
>> class_<X>() [
>> def(..., &X::f); #1
>> ]
>>
>> #1 needs access to `X` from the enclosing class_<>.
>
> Right. It may not be entirely obvious why at first, but if you look
> at the Boost.Python code that handles this, you'll see it. X::f might
> actually be declared in a (non-exposed) base class of X, in which case
> the type of its address doesn't actually have any way to deduce X at
> all.