Front-end

[ 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
fishcorngmail.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://sourcefor
ge.net/powerbar/db2/
_______________________________________________
Boost-langbinding mailing list
Boost-langbindinglists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/boost
-langbinding

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://sourcefor
ge.net/powerbar/db2/
_______________________________________________
Boost-langbinding mailing list
Boost-langbindinglists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/boost
-langbinding

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
fishcorngmail.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://sourcefor
ge.net/powerbar/db2/
_______________________________________________
Boost-langbinding mailing list
Boost-langbindinglists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/boost
-langbinding

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-cons
ulting.com

The Astoria Seminar ==> http://www.astoriasemin
ar.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://sourcefor
ge.net/powerbar/db2/
_______________________________________________
Boost-langbinding mailing list
Boost-langbindinglists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/boost
-langbinding

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
fishcorngmail.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://sourcefor
ge.net/powerbar/db2/
_______________________________________________
Boost-langbinding mailing list
Boost-langbindinglists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/boost
-langbinding

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.boos
t.org/libs/python/doc/tutorial/doc/html/python/functions.htm
l#python.call_policies
http://boost.org/libs/python/doc/v2/Ca
llPolicies.html#CallPolicies-concept

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

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

The Astoria Seminar ==> http://www.astoriasemin
ar.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://sourcefor
ge.net/powerbar/db2/
_______________________________________________
Boost-langbinding mailing list
Boost-langbindinglists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/boost
-langbinding

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.boos
t.org/libs/python/doc/tutorial/doc/html/python/functions.htm
l#python.call_policies
> http://boost.org/libs/python/doc/v2/Ca
llPolicies.html#CallPolicies-concept
> 
> And also maybe Luabind:
> http://www.rasterbar.com/products/luabind/docs.html#
policies

Will do.

-- 

John Moeller
fishcorngmail.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://sourcefor
ge.net/powerbar/db2/
_______________________________________________
Boost-langbinding mailing list
Boost-langbindinglists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/boost
-langbinding