DSEL syntax, or opening the can of worms.

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

DSEL syntax, or opening the can of worms.

Rene Rivera-2
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:

namespace a
{
   int f();

   struct A
   {
     void do();

     struct B
     {
       void again();
     };
   };
}

In Luabind the binding declaration would look like:

module(L)
[
   namespace_(L,"a")
   [
     def("f",&a::f),
     class<a::A>("A")
       .def("do",&a::A::do)
       .scope
       [
         class_<a::A::B>("B")
           .def("again",&a::A::B::again)
       ]
   ]
]

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):

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?


--
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Boost-langbinding mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/boost-langbinding
Reply | Threaded
Open this post in threaded view
|

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

Roman Yakovenko
On 8/8/07, Rene Rivera <[hidden email]> wrote:

> 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:
>
> namespace a
> {
>    int f();
>
>    struct A
>    {
>      void do();
>
>      struct B
>      {
>        void again();
>      };
>    };
> }
>
> In Luabind the binding declaration would look like:
>
> module(L)
> [
>    namespace_(L,"a")
>    [
>      def("f",&a::f),
>      class<a::A>("A")
>        .def("do",&a::A::do)
>        .scope
>        [
>          class_<a::A::B>("B")
>            .def("again",&a::A::B::again)
>        ]
>    ]
> ]
>
> 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):
>
> 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.

Boost.Python code looks familiar to Python users:

class< X > ( "X" )
    .def( ... )
    .def( ... );

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.


--
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Boost-langbinding mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/boost-langbinding
Reply | Threaded
Open this post in threaded view
|

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

Daniel Wallin-2
In reply to this post by Rene Rivera-2
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.

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.

--
Daniel Wallin
Boost Consulting
www.boost-consulting.com


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Boost-langbinding mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/boost-langbinding
Reply | Threaded
Open this post in threaded view
|

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

John Moeller
In reply to this post by Rene Rivera-2
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?

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.

--

John Moeller
[hidden email]


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Boost-langbinding mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/boost-langbinding
Reply | Threaded
Open this post in threaded view
|

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

John Moeller
In reply to this post by Daniel Wallin-2
Daniel Wallin wrote:

> 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.

--

John Moeller
[hidden email]


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Boost-langbinding mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/boost-langbinding
Reply | Threaded
Open this post in threaded view
|

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

Daniel Wallin-2
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.

--
Daniel Wallin
Boost Consulting
www.boost-consulting.com


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Boost-langbinding mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/boost-langbinding
Reply | Threaded
Open this post in threaded view
|

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

David Abrahams
In reply to this post by John Moeller

on Wed Aug 08 2007, John Moeller <fishcorn-AT-gmail.com> wrote:

> 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?
>
> I don't think it was ever discussed;

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.

--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

The Astoria Seminar ==> http://www.astoriaseminar.com


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Boost-langbinding mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/boost-langbinding
Reply | Threaded
Open this post in threaded view
|

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

David Abrahams
In reply to this post by Daniel Wallin-2

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.

--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

The Astoria Seminar ==> http://www.astoriaseminar.com


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Boost-langbinding mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/boost-langbinding
Reply | Threaded
Open this post in threaded view
|

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

John Moeller
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.

Ah, ok.  That makes sense.

--

John Moeller
[hidden email]


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Boost-langbinding mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/boost-langbinding