Front-end

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

Front-end

John Moeller
[ Ok, I'm not doing well at staying coherent on other topics, so I'll
change the subject.  :) ]

I was wondering about the front-end a little bit, and since it would be
essentially a DSEL, has any thought been given toward using Proto for
the Langbinding front-end?

I think that it could potentially save a lot of time in the front-end
design.

--

John Moeller
[hidden email]

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Boost-langbinding mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/boost-langbinding
Reply | Threaded
Open this post in threaded view
|

Re: Front-end

Daniel Wallin-2
John Moeller wrote:
> [ Ok, I'm not doing well at staying coherent on other topics, so I'll
> change the subject.  :) ]
>
> I was wondering about the front-end a little bit, and since it would be
> essentially a DSEL, has any thought been given toward using Proto for
> the Langbinding front-end?

I don't know which DSEL you're thinking of. IIRC we use type erasure
everywhere, in which case proto won't help. We might have some parts
that doesn't use type erasure, like the policy specification syntax, but
 I don't think we'd want to do any tree transformations on that anyway..

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


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Boost-langbinding mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/boost-langbinding
Reply | Threaded
Open this post in threaded view
|

Re: Front-end

John Moeller
Daniel Wallin wrote:
> John Moeller wrote:
>> I was wondering about the front-end a little bit, and since it would be
>> essentially a DSEL, has any thought been given toward using Proto for
>> the Langbinding front-end?
>
> I don't know which DSEL you're thinking of.

The class_<>, def(), etc.  It's a DSEL that describes a class.

> IIRC we use type erasure
> everywhere, in which case proto won't help.

Type erasure.  That's the term I was looking for, thank you.  :)

There's only type erasure (AFAICT) at the point where xxx binds.  Tuple
transformations and other compile-time operations are used internally in
langbinding.  All I'm saying is that it may be useful.  If you don't
think so, so be it.

Additionally, I've been wondering if type erasure is strictly necessary
anyway.  A while back, you and Dave had discussed a system where static
type information was utilized.  It seems that the idea of static
converter generators was abandoned in favor of type erasure, but I
wasn't able to discern why.  That's the point that I was trying to get
at in my other post.  I wanted to revisit the issue, if possible.

> We might have some parts
> that doesn't use type erasure, like the policy specification syntax, but
>  I don't think we'd want to do any tree transformations on that anyway..

Policy specification syntax?  Are you referring to something in
Boost.Python or in Luabind?

--

John Moeller
[hidden email]


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Boost-langbinding mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/boost-langbinding
Reply | Threaded
Open this post in threaded view
|

Re: Front-end

David Abrahams

on Sat Jun 30 2007, John Moeller <fishcorn-AT-gmail.com> wrote:

> Daniel Wallin wrote:
>> John Moeller wrote:
>>> I was wondering about the front-end a little bit, and since it would be
>>> essentially a DSEL, has any thought been given toward using Proto for
>>> the Langbinding front-end?
>>
>> I don't know which DSEL you're thinking of.
>
> The class_<>, def(), etc.  It's a DSEL that describes a class.
>
>> IIRC we use type erasure
>> everywhere, in which case proto won't help.
>
> Type erasure.  That's the term I was looking for, thank you.  :)
>
> There's only type erasure (AFAICT) at the point where xxx binds.  Tuple
> transformations and other compile-time operations are used internally in
> langbinding.  All I'm saying is that it may be useful.  If you don't
> think so, so be it.

It would be useful if we needed to statically generate
language-specific bindings from the user's binding code.  However,
it's our hope to avoid that.

> Additionally, I've been wondering if type erasure is strictly necessary
> anyway.  A while back, you and Dave had discussed a system where static
> type information was utilized.  

Static type information will always be "utilized."

> It seems that the idea of static converter generators was abandoned
> in favor of type erasure, but I wasn't able to discern why.  

It enables us to have a single compiled front-end language binding
that can be used with any number of backend languages.

> That's the point that I was trying to get at in my other post.  I
> wanted to revisit the issue, if possible.

I don't think it's possible to get any advantage out of keeping more
static information around... but I still have to get to your other
posts ;-)

>> We might have some parts
>> that doesn't use type erasure, like the policy specification syntax, but
>>  I don't think we'd want to do any tree transformations on that anyway..
>
> Policy specification syntax?  Are you referring to something in
> Boost.Python or in Luabind?

Something proposed for Langbinding.

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

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


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Boost-langbinding mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/boost-langbinding
Reply | Threaded
Open this post in threaded view
|

Re: Front-end

John Moeller
David Abrahams wrote:

> on Sat Jun 30 2007, John Moeller <fishcorn-AT-gmail.com> wrote:
>
>> Daniel Wallin wrote:
>>> John Moeller wrote:
>>>> I was wondering about the front-end a little bit, and since it would be
>>>> essentially a DSEL, has any thought been given toward using Proto for
>>>> the Langbinding front-end?
>>> I don't know which DSEL you're thinking of.
>> The class_<>, def(), etc.  It's a DSEL that describes a class.
>>
>>> IIRC we use type erasure
>>> everywhere, in which case proto won't help.
>> Type erasure.  That's the term I was looking for, thank you.  :)
>>
>> There's only type erasure (AFAICT) at the point where xxx binds.  Tuple
>> transformations and other compile-time operations are used internally in
>> langbinding.  All I'm saying is that it may be useful.  If you don't
>> think so, so be it.
>
> It would be useful if we needed to statically generate
> language-specific bindings from the user's binding code.  However,
> it's our hope to avoid that.

Ok.  I'll try to invent another use for proto outside langbinding.  It's
just so neat!

>> Additionally, I've been wondering if type erasure is strictly necessary
>> anyway.  A while back, you and Dave had discussed a system where static
>> type information was utilized.  
>
> Static type information will always be "utilized."

Hm.  That was vague, wasn't it?  Let me modify that to say, "utilized to
determine xxx argument types."  I see now that that goes against the
"compile-once-bind-anywhere" idea.

>> It seems that the idea of static converter generators was abandoned
>> in favor of type erasure, but I wasn't able to discern why.  
>
> It enables us to have a single compiled front-end language binding
> that can be used with any number of backend languages.

That makes sense.

Ugh.  The "frontend"/"backend" thing is making me dizzy.  I tried to
come up with alternatives ("native" to replace "frontend", for example),
but I couldn't think of any role-independent terms for backend languages.

>> That's the point that I was trying to get at in my other post.  I
>> wanted to revisit the issue, if possible.
>
> I don't think it's possible to get any advantage out of keeping more
> static information around... but I still have to get to your other
> posts ;-)

Ok.  Sorry if I sounded urgent.  :-)  I know that it takes time.

>>> We might have some parts
>>> that doesn't use type erasure, like the policy specification syntax, but
>>>  I don't think we'd want to do any tree transformations on that anyway..
>> Policy specification syntax?  Are you referring to something in
>> Boost.Python or in Luabind?
>
> Something proposed for Langbinding.

Cool!  Let's get it codified.  :-)  Was that one of the discussions I
found in the archives, and I just didn't absorb it?  And by "policy" do
you mean Alexandrescu-like policies, or something else?  I know there
was a debate over the term "policy."

--

John Moeller
[hidden email]


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Boost-langbinding mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/boost-langbinding
Reply | Threaded
Open this post in threaded view
|

Re: Front-end

David Abrahams

on Tue Jul 03 2007, John Moeller <fishcorn-AT-gmail.com> wrote:

>>> That's the point that I was trying to get at in my other post.  I
>>> wanted to revisit the issue, if possible.
>>
>> I don't think it's possible to get any advantage out of keeping more
>> static information around... but I still have to get to your other
>> posts ;-)
>
> Ok.  Sorry if I sounded urgent.  :-)  I know that it takes time.

I wasn't hurried, just embarassed.

>>>> We might have some parts
>>>> that doesn't use type erasure, like the policy specification syntax, but
>>>>  I don't think we'd want to do any tree transformations on that anyway..
>>> Policy specification syntax?  Are you referring to something in
>>> Boost.Python or in Luabind?
>>
>> Something proposed for Langbinding.
>
> Cool!  Let's get it codified.  :-)  Was that one of the discussions I
> found in the archives, and I just didn't absorb it?  

See pp 9-14 of http://www.boost-consulting.com/writing/langbinding.ppt

> And by "policy" do you mean Alexandrescu-like policies, or something
> else?  

Depends what you mean by "Alexandrescu-like."  

I suggest you read up on call policies in Boost.Python.
http://www.boost.org/libs/python/doc/tutorial/doc/html/python/functions.html#python.call_policies
http://boost.org/libs/python/doc/v2/CallPolicies.html#CallPolicies-concept

And also maybe Luabind:
http://www.rasterbar.com/products/luabind/docs.html#policies

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

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


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Boost-langbinding mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/boost-langbinding
Reply | Threaded
Open this post in threaded view
|

Re: Front-end

John Moeller
David Abrahams wrote:
> on Tue Jul 03 2007, John Moeller <fishcorn-AT-gmail.com> wrote:
>> Cool!  Let's get it codified.  :-)  Was that one of the discussions I
>> found in the archives, and I just didn't absorb it?  
>
> See pp 9-14 of http://www.boost-consulting.com/writing/langbinding.ppt

Ah, ok.  I'd read that, but hadn't thought to connect the "policies"
moniker to it.

>> And by "policy" do you mean Alexandrescu-like policies, or something
>> else?  
>
> Depends what you mean by "Alexandrescu-like."  

I answered this question for myself after you pointed me back to the
.ppt.  I meant policies that exist as types and affect the type of
classes that use them.  Call policies wouldn't fall under that category
exactly, but they do affect the behavior of bindings that use them, it
seems.

> I suggest you read up on call policies in Boost.Python.
> http://www.boost.org/libs/python/doc/tutorial/doc/html/python/functions.html#python.call_policies
> http://boost.org/libs/python/doc/v2/CallPolicies.html#CallPolicies-concept
>
> And also maybe Luabind:
> http://www.rasterbar.com/products/luabind/docs.html#policies

Will do.

--

John Moeller
[hidden email]


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Boost-langbinding mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/boost-langbinding