On Monday, 25 August 2014 at 19:26:59 UTC, Brost wrote:
> Protocols are basically the way to "standardize" or describe
> something that can be implemented in many different way; I know
> that if you start from the ABI or the compiled object you are
> basically going nowhere because you are focusing on
> implementation specific details and limitations.
> That's what I was expecting, something like a protocol .

Ok, but formally a protocol is just a structured technique for exchange between entities.

So the D protocol is the means to obtain typeinfo at compile time. Then you can translate the "D typeinfo protocol" into another protocol of your own choice?

It seems to me that all you need is a list of types you want to export. From this you should be able to write your own protocol by annotating members you want to export with user defined attributes?

http://dlang.org/expression.html#typeidexpression
http://dlang.org/phobos/object.html#.TypeInfo
http://dlang.org/phobos/object.html#.OffsetTypeInfo
http://dlang.org/traits.html#allMembers
http://dlang.org/traits.html#getMember
http://dlang.org/traits.html#getAttributes
…

Seems to be a workable solution to me.

Ola.

On 25/08/14 22:34, "Marc Schütz" <schuetzm@gmx.net>" wrote:

> Take Ruby as an example: Ruby is a scripting language that cannot be
> compiled to native code (though it can be JITted).

Both MacRuby [1] and RubyMotion [2] supports ahead of time compilation. I'm pretty sure Apple doesn't allow anything else than compiled languages on iOS. Except for HTML and JavaScript.

[1] http://macruby.org/
[2] http://www.rubymotion.com/

-- 
/Jacob Carlborg

On Tuesday, 26 August 2014 at 06:44:52 UTC, Jacob Carlborg wrote:
> Both MacRuby [1] and RubyMotion [2] supports ahead of time compilation. I'm pretty sure Apple doesn't allow anything else than compiled languages on iOS. Except for HTML and JavaScript.

I think Apple changed this policy in 2010, but IIRC they don't allow execution of downloaded scripts outside a webview.

On Tuesday, 26 August 2014 at 06:44:52 UTC, Jacob Carlborg wrote:
> On 25/08/14 22:34, "Marc Schütz" <schuetzm@gmx.net>" wrote:
>
>> Take Ruby as an example: Ruby is a scripting language that cannot be
>> compiled to native code (though it can be JITted).
>
> Both MacRuby [1] and RubyMotion [2] supports ahead of time compilation. I'm pretty sure Apple doesn't allow anything else than compiled languages on iOS. Except for HTML and JavaScript.
>
> [1] http://macruby.org/
> [2] http://www.rubymotion.com/

I've heard about them, but I don't know any details. Anyway, the way Ruby works, they either need to restrict the language, include a full interpreter/jitter, or at most they could only translate it to a very abstract level. Like for an expression like `a + b` generating a call to a helper function like `send(_var_a, SYMBOL(":+"), _var_b);`, and hoping that the compiler backend can eliminate this in some cases.

But this doesn't really change my point: it's just another two ABIs, and their probably not meant to be public interfaces, to let the implementers keep some freedom for future developments.

On 26/08/14 13:40, "Marc Schütz" <schuetzm@gmx.net>" wrote:

> I've heard about them, but I don't know any details. Anyway, the way
> Ruby works, they either need to restrict the language, include a full
> interpreter/jitter, or at most they could only translate it to a very
> abstract level. Like for an expression like `a + b` generating a call to
> a helper function like `send(_var_a, SYMBOL(":+"), _var_b);`, and hoping
> that the compiler backend can eliminate this in some cases.

It's implemented on top of Objective-C.

Yeah, it needs to be able to interpret or JIT, otherwise a lot of meta programming and things like "eval" won't work. Although, I'm not sure about RubyMotion. I don't think you can use regular Ruby gems out of the box with RubyMotion.

-- 
/Jacob Carlborg

On Tuesday, 26 August 2014 at 14:46:56 UTC, Jacob Carlborg wrote:
> On 26/08/14 13:40, "Marc Schütz" <schuetzm@gmx.net>" wrote:
>
>> I've heard about them, but I don't know any details. Anyway, the way
>> Ruby works, they either need to restrict the language, include a full
>> interpreter/jitter, or at most they could only translate it to a very
>> abstract level. Like for an expression like `a + b` generating a call to
>> a helper function like `send(_var_a, SYMBOL(":+"), _var_b);`, and hoping
>> that the compiler backend can eliminate this in some cases.
>
> It's implemented on top of Objective-C.

This makes sense, Objective-C can cope with classes that change at runtime. Singleton methods are probably more challenging, though...

Le 25/08/2014 09:18, Brost a écrit :
> On Monday, 25 August 2014 at 06:44:25 UTC, Jacob Carlborg wrote:
>> On 25/08/14 08:18, Brost wrote:
>>
>>> Is D different in this regard ?
>>
>> In addition to being ABI compatible with C, D is also compatible with
>> C++ [1]. D recently got support for C++ templates and namespaces.
>> Hopefully it will get support for Objective-C as well, in the not too
>> far away future.
>>
>> [1] http://dlang.org/cpp_interface.html
>
> thanks, but unfortunately neither of those is a scripting
> language, I can't see any facility in the standard D library or
> in the language that can help me retain the type safety, the
> memory management, and all the other things I talked about while
> interfacing with another language .
>

You just can't introduce type safety to a scripting language without modifying the VM implementation, you may search if there is some fork of the library doing that.


> for example how do you correctly expose a given D data structure
> to a scripting language of your choice ?

In DQuick we expose D object to the Lua VM by using the Lua C library.
Its API allow us to expose D structures or classes directly.

If the API of the VM of your scripting language is written in C, it's almost the same as if you write a C++ application.

Le 26/08/2014 10:59, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" a écrit :
> On Tuesday, 26 August 2014 at 06:44:52 UTC, Jacob Carlborg wrote:
>> Both MacRuby [1] and RubyMotion [2] supports ahead of time
>> compilation. I'm pretty sure Apple doesn't allow anything else than
>> compiled languages on iOS. Except for HTML and JavaScript.
>
> I think Apple changed this policy in 2010, but IIRC they don't allow
> execution of downloaded scripts outside a webview.

JIT is always no authorized.

On Wednesday, 3 September 2014 at 23:04:13 UTC, Xavier Bigand wrote:
> JIT is always no authorized.

Not accurate. You are allowed to use Nitro.