August 25, 2014 Re: How D addresses the problem of Extending and/or Embedding other languages ? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Brost | 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. |
August 26, 2014 Re: How D addresses the problem of Extending and/or Embedding other languages ? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Marc Schütz | 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 |
August 26, 2014 Re: How D addresses the problem of Extending and/or Embedding other languages ? | ||||
---|---|---|---|---|
| ||||
Posted in reply to 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.
|
August 26, 2014 Re: How D addresses the problem of Extending and/or Embedding other languages ? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | 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.
|
August 26, 2014 Re: How D addresses the problem of Extending and/or Embedding other languages ? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Marc Schütz | 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 |
August 26, 2014 Re: How D addresses the problem of Extending and/or Embedding other languages ? | ||||
---|---|---|---|---|
| ||||
Posted in reply to 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...
|
September 03, 2014 Re: How D addresses the problem of Extending and/or Embedding other languages ? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Brost | 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. |
September 03, 2014 Re: How D addresses the problem of Extending and/or Embedding other languages ? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ola Fosheim Grøstad | 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. |
September 04, 2014 Re: How D addresses the problem of Extending and/or Embedding other languages ? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Xavier Bigand | 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.
|
Copyright © 1999-2021 by the D Language Foundation