"Patrick Down" <pat@codemoon.com> wrote in message news:Xns91FF8288ECF6Fpatcodemooncom@63.105.9.61...
> Burton Radons <loth@users.sourceforge.net> wrote in
> news:br5qcuo879plqcnr60avcraeamqu318phr@4ax.com:
> I've done a lot of C++/Python integration too.  It's true that code to
> hook the two together is a pain.  I eventually invented my own IDL
> language.
> I would run it through a script that would auto generate 99.9% of the
> hook
> code for me.  Of course the runtime bulk is still there.

What would it take to implement in D:

    extern (Python) int some_python_function(int foo);

basically, make D really easy to interface to Python?

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3CCD9200.64D5035D@deming-os.org...
> Even if Walter doesn't feel like supporting it...we could do it.

It's not a matter of feeling like it, it's just that I'm supporting 4 compilers simultaneously, and I get stretched a little thin. People ask me why I don't play chess, etc. After working on compilers all night, I prefer mindless entertainment <g>.

Anyhow, source to the D front end is now part of the distribution, and if anyone wants to morph that into an interpretted version, that would be a cool addition to D.

Also, any gcc experts out there want to create a gcc version of the D compiler?

"Patrick Down" <pat@codemoon.com> wrote in message news:Xns91FF9D202AFD6patcodemooncom@63.105.9.61...
> I like the idea of a standard interpreter module although as I said in a different thread here what I really want is a embeddable JIT compiler module.  But in the mean time I'll take a regular old script interpreter.  I've thought about doing this for D if I have some spare time.

What do people think of adding an ECMAScript interpreter as a Phobos library routine? (ECMAScript is the official name for javascript, jscript, etc.)

"Patrick Down" <pat@codemoon.com> wrote in message news:Xns91FFAE8EF54EFpatcodemooncom@63.105.9.61...
> Russ Lewis <spamhole-2001-07-16@deming-os.org> wrote in news:3CCDB223.17897881@deming-os.org:
>
> > Patrick Down wrote:
> >
> > I don't know Python, so this is just a shot in the dark, but...could you define a "Python" calling convention?  D already supports multiple calling conventions, and this could be another:
> >
> >     extern(Python) void MyFunc(...);
>
> Yes but there are a lot of scripting languages out there. I wouldn't ask Walter to support all of them, even Python. :-)  It's a task better left to an third party tool.

I've received many requests for supporting an interface to Python. Interestingly, people who find D appealing also find Python appealing for their scripting needs.

On Wed, 1 May 2002 03:42:54 -0700, "Walter" <walter@digitalmars.com> wrote:

>
>"Patrick Down" <pat@codemoon.com> wrote in message news:Xns91FF8288ECF6Fpatcodemooncom@63.105.9.61...
>> Burton Radons <loth@users.sourceforge.net> wrote in
>> news:br5qcuo879plqcnr60avcraeamqu318phr@4ax.com:
>> I've done a lot of C++/Python integration too.  It's true that code to
>> hook the two together is a pain.  I eventually invented my own IDL
>> language.
>> I would run it through a script that would auto generate 99.9% of the
>> hook
>> code for me.  Of course the runtime bulk is still there.
>
>What would it take to implement in D:
>
>    extern (Python) int some_python_function(int foo);
>
>basically, make D really easy to interface to Python?

The more common direction, by a gigantic majority, is calling X from Python rather than Python from X.  In my code the number of such cases can be counted on a hand that has fought with a wood chipper: three times, out of perhaps a thousand functions and methods.

For all three times I don't see any way that they could be supported automatically; each has really specialized circumstances.

Similarly classes are far more common than functions (although that will vary with the project, of course).  Until recently you couldn't subclass builtin types in Python, and that would be easier to support. You could support Python subclassed types, however, by preprocessing a proxy class, and that would even allow calling Python-overloaded methods from D.

So I think this should be alotted to a preprocessor that takes a D file and constructs an interface to Python, like SWIG, but more automatic.  There's no magic bullet, that's for sure.  D does help make it easier, but it's a lot of work in any case.

Walter wrote:

> "Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3CCD9200.64D5035D@deming-os.org...
> > Even if Walter doesn't feel like supporting it...we could do it.
>
> It's not a matter of feeling like it, it's just that I'm supporting 4 compilers simultaneously, and I get stretched a little thin. People ask me why I don't play chess, etc. After working on compilers all night, I prefer mindless entertainment <g>.

Sorry, I very definitely did NOT mean that to sound like you were lazy, random, or arbitrary.  I am VERY happy that you put all this work into D.  Like I said when I first arrived at this newsgroup...I'd been working on a spec very much like your D spec for a year or more, but I had exactly 0 lines of code actually written for it.

(gets up on soapbox)

Hear ye!  Hear ye!  Walter Bright is a good, hard working man!  Let all gather together with me and express their great appreciation for his long hours and his willingness to give (at least some of it) away for free!  Hear ye!  Hear ye!

(gets down, laughs at self)

> Anyhow, source to the D front end is now part of the distribution, and if anyone wants to morph that into an interpretted version, that would be a cool addition to D.

I'm going to have to look at the code you've written for that...is it architected where somebody could remove your code and drop in an alternative version, or would it be a pretty involved port?

In a perfect world, there would be a parser module that turns D code into a recursive set of structures that could then be passed to any arbitrary backend: an interpreter, a GCC frontend, a dfront translator, or even a D-- compiler.

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

"Walter" <walter@digitalmars.com> wrote in message news:aaoh8b$2qe7$2@digitaldaemon.com...

> What do people think of adding an ECMAScript interpreter as a Phobos
library
> routine? (ECMAScript is the official name for javascript, jscript, etc.)

You mean, that one you've written?
Anyhow, YES. Some standartized way to do scripting would be just great.
It's nice to have such a handy tool as a part of distribution: no need
to search for 3rd-party libs, try to compile them, then find out they
crash every second call...

In article <7oovcukrmtcvnvvlbuhh9s0vup7b9mk9nd@4ax.com>,
 Burton Radons <loth@users.sourceforge.net> wrote:
[...]
> The more common direction, by a gigantic majority, is calling X from Python rather than Python from X.  In my code the number of such cases can be counted on a hand that has fought with a wood chipper: three times, out of perhaps a thousand functions and methods.
> 
> For all three times I don't see any way that they could be supported automatically; each has really specialized circumstances.
> 
> Similarly classes are far more common than functions (although that will vary with the project, of course).  Until recently you couldn't subclass builtin types in Python, and that would be easier to support. You could support Python subclassed types, however, by preprocessing a proxy class, and that would even allow calling Python-overloaded methods from D.
> 
> So I think this should be alotted to a preprocessor that takes a D file and constructs an interface to Python, like SWIG, but more automatic.  There's no magic bullet, that's for sure.  D does help make it easier, but it's a lot of work in any case.

Interesting thing about Objective-C is how well it can work with Java, Ruby, and Python without needing pre-processing of code... The thing those four languages have in common is good reflection/introspection.

For calling any of those languages from ObjectiveC, you can take advantage of the fact that polymorphism in ObjectiveC does NOT require inheritance.

You can call any method on (that is, "send any message to") any object. If that object doesn't understand that method/message, then the run-time code will invoke the method "forwardInvocation:" on the object (if it exists), passing in as the argument information about the originally intended message and arguments. In that object's implementation of "forwardInvocation:", it can use functions in Java (via JNI), Python, Ruby, etc., to forward that call and arguments to that other language. The same technique is used for 'distributed objects' -- forwarding calls through a network to a remote computer.

More information about this is in:

<http://developer.apple.com/techpubs/macosx/Cocoa/ObjectiveC/5RunTime/For warding.html>

<http://developer.apple.com/techpubs/macosx/Cocoa/ObjectiveC/4MoreObjC/iR emote_Messaging.html>

You might ask, if Objective C is so wonderful, why don't more people use it. I think three reasons:

One, early implementations of Objective C were proprietary and expensive, so it lost mindshare to C++, which was being given away (in the form of cfront) to universities by AT&T.

Two, the 'object-oriented' portions of Objective C use a syntax similar to Smalltalk, which is looks alien to C programmers.

Three, the current maintainer of the Objective C FAQ wrote his own 'non-standard' Objective C implementation, and hates Apple/Next. Since most questions on the objective C newsgroup are asked by people using Apple/Cocoa or NextStep, those message threads turn into flames-fests regularly. (Is there any other newsgroup where the FAQ maintainer is also the resident troll?)

Today, Objective C is available in gcc, so the only thing preventing people from using it is their lack of familiarity (few environments require Objective C, so few people take the time to learn it) and the lack of good objective-c run-time library on the user's platform.

For example, on MacOS 9, I'm not aware of any useful implementation of the Objective-c run-time library. On other platforms, the run-time library is there (provided by gnu), but it may not have the full breadth of capabilities of the one NeXT developed and that is now in Apple's MacOS X -- for example, the gnu implementation of objective-c run-time library may not have distributed (over networks) objects support.

Even though the Objective C syntax is 'alien', it is simple to learn -- much simpler than C++. Of course, it doesn't have templates and operator-overloading, but that is what makes it easy to learn. People who rely on Objective C love the syntax, since it basically names each argument.

   [anInvocation invokeWithTarget:someOtherObject];
is equivalent to C++
   anInvocation->invokeWithTarget( someOtherObject );

Now imagine that there are more arguments...

   [anObject setWidth: 12.0 height: 13.0 colorMode: 'gray'
       taxes: 'irs' filmMaker: 'woo' star: 'sirius' ];
is equivalent to
   anObject->setLotsOfStuff(12.0, 13.0, 'gray', 'irs', 'sirius', 'woo');

(or was that supposed to be:
   anObject->setLotsOfStuff(12.0, 13.0, 'gray', 'irs', 'woo', 'sirius');
?)

Of course, many IDEs these days let you look up the calling docs for a function or method easily, so this advantage is not as big a deal as it used to be.

To get back to my point. I think the ideal language is simplified C++ with Objective C's runtime support, including the ability to "send a message" to any object and allow a class to implement 'forwardInvocation:' in order to catch unimplemented method-calls and handle them appropriately.

This ability to catch unimplemented method-calls makes interfacing with dynamic languages like Python, Ruby, Java easy.
-- 
C. Keith Ray

<http://homepage.mac.com/keithray/xpminifaq.html>

"Pavel Minayev" <evilone@omen.ru> wrote in message news:aaovcd$t5r$1@digitaldaemon.com...
> "Walter" <walter@digitalmars.com> wrote in message news:aaoh8b$2qe7$2@digitaldaemon.com...
> > What do people think of adding an ECMAScript interpreter as a Phobos
> library
> > routine? (ECMAScript is the official name for javascript, jscript, etc.)
> You mean, that one you've written?

Yes. Gotta find some use for it <g>.

> Anyhow, YES. Some standartized way to do scripting would be just great. It's nice to have such a handy tool as a part of distribution: no need to search for 3rd-party libs, try to compile them, then find out they crash every second call...

The interpreter has been well tested, and is pretty solid.

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3CCFF42C.A7C4906E@deming-os.org...
> Sorry, I very definitely did NOT mean that to sound like you were lazy,
random,
> or arbitrary.  I am VERY happy that you put all this work into D.  Like I
said
> when I first arrived at this newsgroup...I'd been working on a spec very
much
> like your D spec for a year or more, but I had exactly 0 lines of code
actually
> written for it.

Ok!

> (gets up on soapbox)
>
> Hear ye!  Hear ye!  Walter Bright is a good, hard working man!  Let all
gather
> together with me and express their great appreciation for his long hours
and
> his willingness to give (at least some of it) away for free!  Hear ye!
Hear
> ye!
>
> (gets down, laughs at self)

Let's not get carried away here!

> I'm going to have to look at the code you've written for that...is it architected where somebody could remove your code and drop in an
alternative
> version, or would it be a pretty involved port?

The source is for the front end only, so an alternative wouldn't make much sense.

> In a perfect world, there would be a parser module that turns D code into
a
> recursive set of structures that could then be passed to any arbitrary
backend:
> an interpreter, a GCC frontend, a dfront translator, or even a D--
compiler.