> I like Python's power I still don't like it's syntax.  I just can't
> handle using indention as the only indicator of code blocks. :-)
> 

I think Ruby tries to cover this bad feature (at least to me), and
as a better integration with native code (C).
But it as few (far few) support from libraries

Patrick Down wrote:

> Number 1 is not quite so easy to solve.  Having the memory management issue solved does away with some of the interface code but there are still issues with marshalling function parameters between the interpreter and D code.  There are two sides to this.  Calling D functions from the script and calling script functions from D.

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(...);

Thus, you can take functions exported from Python and call them directly from D with no wrapper code (the compiler generates the wrapper); similarly, you can export function TO Python and have Python call your D code.

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

> 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(...);
> 
this was like a dream come true 

Patrick Down wrote:

> 
> I would be cool to do this with D but it would require some restrictions.
> 
> 1. Heavy control over imports
> 2. No pointers
> 3. No asm
> 4. Array bounds checking is always turned on.
> 

For a more theoritical discriptions of restrictions required you could try www.tunes.org .  I believe one of their goals is the production of a HLL which could be checked at compile time disallowing access to privledged code - their site has been updated since last time I looked so I no longer have the link - it probably can be found under subprojects / HLL.

C 2002/4/29

"Russell Borogove" <kaleja@estarcion.com> wrote in message news:3CCD7F65.20705@estarcion.com...
> scripting language). If I remember rightly it was
> compiled to a tokenized or "bytecode"[1] form at game
> build time (or maybe at load time, it's been a while).
> [1] Anyone else hate this term as much as I do?


LOL. I've written interpreters, and while bytecode minimizes object code size, it impairs runtime performance. Better to make your interpreter instructions word size and align them.

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.

Patrick Down wrote:

> 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'm not sure there isn't a way to integrate 3rd party plug-ins into a compiler...what if you could just download a plugin that would add support for the Python calling convention to your D compiler?

--
The Villagers are Online! http://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))) ]

On Mon, 29 Apr 2002 15:03:15 -0400, "Richard Krehbiel" <rich@kastle.com> wrote:

>"Russell Borogove" <kaleja@estarcion.com> wrote in message news:3CCD7F65.20705@estarcion.com...
[snip]
>> I believe they decided to leave security as a "caveat player" thing in favor of performance and the ready availability of tools.
>
>Quake 2 was definitely programmed that way; game modes *are* done in native-code .DLLs.
>
>Here's a link that goes into more detail on Quake 3's mod system:
>
>http://firingsquad.gamers.com/hardware/q3adrivers/default.asp
>
>(I dimly recall John Carmack describing his QVM to native code JIT-compiler, but I can't find any links...)

It's in his .plan records, try (finger.quakeworld.com); I can't recall the date.  However, it is entirely optional to do this.  You can go through the full machine code route purely at your own option.

Accountability and peer review pretty much eliminates the danger there.  Can anyone think of one instance where this hole was exploited by a cracker?  One?  Otherwise understand if I'm dubious about this being a real problem... or whether it is relevant to us in any case.

We have the compiler; we can define restricted compilation; it can be as secure as restricted execution in interpreted languages; it is no more difficult to make it secure than it is to make an interpreted language secure.

If restricted compilation is not enough, uh, use an interpreted language.  Better yet, convert your simplified scripting language to D and compile that.  I haven't claimed a panacea here.

On Mon, 29 Apr 2002 14:54:06 -0700, "Walter" <walter@digitalmars.com> wrote:

>"Russell Borogove" <kaleja@estarcion.com> wrote in message news:3CCD7F65.20705@estarcion.com...
>> scripting language). If I remember rightly it was
>> compiled to a tokenized or "bytecode"[1] form at game
>> build time (or maybe at load time, it's been a while).
>> [1] Anyone else hate this term as much as I do?
>
>LOL. I've written interpreters, and while bytecode minimizes object code size, it impairs runtime performance. Better to make your interpreter instructions word size and align them.

The FORTH way is to make these function pointers to call, then in the functions tail into the next instruction using jmp (gforth does this). Very fast stuff and smaller than native code, but bound to be eclipsed in the future by optimising native code compilers (bigforth does this).

"Burton Radons" <loth@users.sourceforge.net> wrote in message news:bisrcu4ng7qcqartp3cec51mb851bqviep@4ax.com...
> On Mon, 29 Apr 2002 14:54:06 -0700, "Walter" <walter@digitalmars.com> wrote:
> >"Russell Borogove" <kaleja@estarcion.com> wrote in message news:3CCD7F65.20705@estarcion.com...
> >> scripting language). If I remember rightly it was
> >> compiled to a tokenized or "bytecode"[1] form at game
> >> build time (or maybe at load time, it's been a while).
> >> [1] Anyone else hate this term as much as I do?
> >LOL. I've written interpreters, and while bytecode minimizes object code size, it impairs runtime performance. Better to make your interpreter instructions word size and align them.
> The FORTH way is to make these function pointers to call, then in the functions tail into the next instruction using jmp (gforth does this). Very fast stuff and smaller than native code, but bound to be eclipsed in the future by optimising native code compilers (bigforth does this).

Ah yes, threaded code.