On Tuesday, 6 May 2014 at 23:19:47 UTC, Mason McGill wrote:
> On Tuesday, 6 May 2014 at 11:28:21 UTC, Chris wrote:
>> Maybe it's time to think about a D interface to Julia. If Julia catches on within the scientific community, it would be good to have a foot in the door. Science quickly creates large code bases, unfortunately, so far it's mostly Python and Matlab which makes it hard to use the algorithms in real world applications.
>
> I've actually been working on just that, on and off for a few months now. Such a thing is kind of "anti-Julian", though, since one of Julia's main goals is to reduce or eliminate the need for mixed-language projects.
>
> However, with D, you can compile small shared libraries that can be automatically bound to your users' favorite dynamic runtimes (via compile-time reflection). I'm hoping this will be good for both D and Julia, allowing library developers to reach a broader audience, and library consumers greater flexibility.
>
> I'll post on the D "announce" thread when I have something working, and I'd definitely appreciate tests/bug-reports at that time!

I was also thinking in the direction of enabling D to use existing Julia code seamlessly, so you can just call it from D (extern(J)), and maybe even efficiently compile it into binaries along with D code, as you would with extern(C) calls now.

On Wednesday, 7 May 2014 at 07:27:42 UTC, Mason McGill wrote:
> On Tuesday, 6 May 2014 at 21:00:18 UTC, bearophile wrote:
>> The language tries its best to be flexible as a dynamic language. But variables never carry a run-time type tag, unlike in Lisp.
>
> Hmm... Then how can I do this:
>
>   x = 5
>   typeof(x) # evaluates to "Int64"
>   x = 5.0
>   typeof(x) # evaluates to "Float64"
>
> ?
>
> Is Julia doing something trickier than I think it is? Or do you just mean they don't carry type tags after compilation?

Maybe the first x stops existing, and a new one is created on reassignment?

A more interesting case is this (pseudo code, don't know Julia syntax):

    x = 5
    if (...) {
        x = "Hello"
    }
    typeof(x) # ???

Is that disallowed?

On Tuesday, 6 May 2014 at 21:31:32 UTC, bearophile wrote:
> Paulo Pinto:
>
>> That is an implementation detail I would say,
>
> It's not an implementation detail, it has consequences on the kind of code you are allowed to write, because it's not really a dynamic language.  After the JIT compilation it's "statically" typed, with some niceties like the type splitting you have seen with the x variable. In Julia you can't write all the programs you can write in Python. But in practice the limitations are not a problem for the scientific code, and the advantages are great.
>
> Bye,
> bearophile

So this basically means:

setName(name)
  userName = name;  // string type

extern module / cracker:

setName(5.0)  // Error or at least doesn't affect original userName

Right or wrong?

On Wednesday, 7 May 2014 at 09:16:01 UTC, Chris wrote:
> On Tuesday, 6 May 2014 at 23:19:47 UTC, Mason McGill wrote:
>> On Tuesday, 6 May 2014 at 11:28:21 UTC, Chris wrote:
>>> Maybe it's time to think about a D interface to Julia. If Julia catches on within the scientific community, it would be good to have a foot in the door. Science quickly creates large code bases, unfortunately, so far it's mostly Python and Matlab which makes it hard to use the algorithms in real world applications.
>>
>> I've actually been working on just that, on and off for a few months now. Such a thing is kind of "anti-Julian", though, since one of Julia's main goals is to reduce or eliminate the need for mixed-language projects.
>>
>> However, with D, you can compile small shared libraries that can be automatically bound to your users' favorite dynamic runtimes (via compile-time reflection). I'm hoping this will be good for both D and Julia, allowing library developers to reach a broader audience, and library consumers greater flexibility.
>>
>> I'll post on the D "announce" thread when I have something working, and I'd definitely appreciate tests/bug-reports at that time!
>
> I was also thinking in the direction of enabling D to use existing Julia code seamlessly, so you can just call it from D (extern(J)), and maybe even efficiently compile it into binaries along with D code, as you would with extern(C) calls now.

That would be very good. If julia is to become a/the norm for scientific computing, D could form the full-power systems/applications partner very neatly.

On Wednesday, 7 May 2014 at 09:16:01 UTC, Chris wrote:
> On Tuesday, 6 May 2014 at 23:19:47 UTC, Mason McGill wrote:
>> On Tuesday, 6 May 2014 at 11:28:21 UTC, Chris wrote:
>>> Maybe it's time to think about a D interface to Julia. If Julia catches on within the scientific community, it would be good to have a foot in the door. Science quickly creates large code bases, unfortunately, so far it's mostly Python and Matlab which makes it hard to use the algorithms in real world applications.
>>
>> I've actually been working on just that, on and off for a few months now. Such a thing is kind of "anti-Julian", though, since one of Julia's main goals is to reduce or eliminate the need for mixed-language projects.
>>
>> However, with D, you can compile small shared libraries that can be automatically bound to your users' favorite dynamic runtimes (via compile-time reflection). I'm hoping this will be good for both D and Julia, allowing library developers to reach a broader audience, and library consumers greater flexibility.
>>
>> I'll post on the D "announce" thread when I have something working, and I'd definitely appreciate tests/bug-reports at that time!
>
> I was also thinking in the direction of enabling D to use existing Julia code seamlessly, so you can just call it from D (extern(J)), and maybe even efficiently compile it into binaries along with D code, as you would with extern(C) calls now.

It's really easy to do that with R. There is a package RInside that makes it trivial to embed R in a C++ program, and it's not difficult to use with D.

On 5/7/14, 6:18 AM, "Marc Schütz" <schuetzm@gmx.net>" wrote:
> On Wednesday, 7 May 2014 at 07:27:42 UTC, Mason McGill wrote:
>> On Tuesday, 6 May 2014 at 21:00:18 UTC, bearophile wrote:
>>> The language tries its best to be flexible as a dynamic language. But
>>> variables never carry a run-time type tag, unlike in Lisp.
>>
>> Hmm... Then how can I do this:
>>
>>   x = 5
>>   typeof(x) # evaluates to "Int64"
>>   x = 5.0
>>   typeof(x) # evaluates to "Float64"
>>
>> ?
>>
>> Is Julia doing something trickier than I think it is? Or do you just
>> mean they don't carry type tags after compilation?
>
> Maybe the first x stops existing, and a new one is created on reassignment?
>
> A more interesting case is this (pseudo code, don't know Julia syntax):
>
>      x = 5
>      if (...) {
>          x = "Hello"
>      }
>      typeof(x) # ???
>
> Is that disallowed?

I just tried it. I also used the code_llvm function to see what llvm is generated. Some lines:

%8 = call %jl_value_t* @jl_box_int32(i32 %0), !dbg !4339

(an int is being boxed and you get a pointer to a jl_value_t)

  %13 = call %jl_value_t* @jl_apply_generic(%jl_value_t* inttoptr (i64 4373507136 to %jl_value_t*), %jl_value_t** %6, i32 2), !dbg !4346

(a generic function call is being made)

So, there clearly must be runtime information associated to the variables, at least when they need boxing or this kind of multi-dispatch at runtime.

On Wednesday, 7 May 2014 at 12:05:10 UTC, bachmeier wrote:
> On Wednesday, 7 May 2014 at 09:16:01 UTC, Chris wrote:
>> On Tuesday, 6 May 2014 at 23:19:47 UTC, Mason McGill wrote:
>>> On Tuesday, 6 May 2014 at 11:28:21 UTC, Chris wrote:
>>>> Maybe it's time to think about a D interface to Julia. If Julia catches on within the scientific community, it would be good to have a foot in the door. Science quickly creates large code bases, unfortunately, so far it's mostly Python and Matlab which makes it hard to use the algorithms in real world applications.
>>>
>>> I've actually been working on just that, on and off for a few months now. Such a thing is kind of "anti-Julian", though, since one of Julia's main goals is to reduce or eliminate the need for mixed-language projects.
>>>
>>> However, with D, you can compile small shared libraries that can be automatically bound to your users' favorite dynamic runtimes (via compile-time reflection). I'm hoping this will be good for both D and Julia, allowing library developers to reach a broader audience, and library consumers greater flexibility.
>>>
>>> I'll post on the D "announce" thread when I have something working, and I'd definitely appreciate tests/bug-reports at that time!
>>
>> I was also thinking in the direction of enabling D to use existing Julia code seamlessly, so you can just call it from D (extern(J)), and maybe even efficiently compile it into binaries along with D code, as you would with extern(C) calls now.
>
> It's really easy to do that with R. There is a package RInside that makes it trivial to embed R in a C++ program, and it's not difficult to use with D.

Would be cool if we had something like this for Julia (if it really catches on).

On Wednesday, 7 May 2014 at 14:57:36 UTC, Chris wrote:
> On Wednesday, 7 May 2014 at 12:05:10 UTC, bachmeier wrote:
>> On Wednesday, 7 May 2014 at 09:16:01 UTC, Chris wrote:
>>> On Tuesday, 6 May 2014 at 23:19:47 UTC, Mason McGill wrote:
>>>> On Tuesday, 6 May 2014 at 11:28:21 UTC, Chris wrote:
>>>>> Maybe it's time to think about a D interface to Julia. If Julia catches on within the scientific community, it would be good to have a foot in the door. Science quickly creates large code bases, unfortunately, so far it's mostly Python and Matlab which makes it hard to use the algorithms in real world applications.
>>>>
>>>> I've actually been working on just that, on and off for a few months now. Such a thing is kind of "anti-Julian", though, since one of Julia's main goals is to reduce or eliminate the need for mixed-language projects.
>>>>
>>>> However, with D, you can compile small shared libraries that can be automatically bound to your users' favorite dynamic runtimes (via compile-time reflection). I'm hoping this will be good for both D and Julia, allowing library developers to reach a broader audience, and library consumers greater flexibility.
>>>>
>>>> I'll post on the D "announce" thread when I have something working, and I'd definitely appreciate tests/bug-reports at that time!
>>>
>>> I was also thinking in the direction of enabling D to use existing Julia code seamlessly, so you can just call it from D (extern(J)), and maybe even efficiently compile it into binaries along with D code, as you would with extern(C) calls now.
>>
>> It's really easy to do that with R. There is a package RInside that makes it trivial to embed R in a C++ program, and it's not difficult to use with D.
>
> Would be cool if we had something like this for Julia (if it really catches on).

I guess you can call D from Julia very easily via the C API and would just need to declare C calling convention in your D code.  It may be that with a combination of Julia and D one has the best of both  worlds - no compromise with speed and efficient resource use on the number crunching with a nice shell / Ipython notebook that is still pretty fast on the front end.

Nicer would be a wrapper a la PyD that seamlessly translates between types.

Then the other thing is to translate julia.h into D so that you can embed Julia.  That's a little work but not so hard.  More about how this works with C here:

http://docs.julialang.org/en/release-0.3/manual/embedding/

On Friday, 12 December 2014 at 06:57:24 UTC, Laeeth Isharc wrote:

> I guess you can call D from Julia very easily via the C API and would just need to declare C calling convention in your D code.
>  It may be that with a combination of Julia and D one has the best of both  worlds - no compromise with speed and efficient resource use on the number crunching with a nice shell / Ipython notebook that is still pretty fast on the front end.
>
> Nicer would be a wrapper a la PyD that seamlessly translates between types.
>
> Then the other thing is to translate julia.h into D so that you can embed Julia.  That's a little work but not so hard.  More about how this works with C here:
>
> http://docs.julialang.org/en/release-0.3/manual/embedding/

That's interesting. I hadn't seen it before.

I communicated with John Myles White via Twitter some months ago, and he said shared libraries for Julia should be coming. That would mean you could compile Julia functions and call them directly from D. This type of embedding is what you get with, say, Guile Scheme. The shared library approach would be a lot more convenient.

The downside about calling embedding Julia is C is that everything's a pointer to the heap and you have to manually call the garbage collector. If the same thing were implemented in D, then D can handle the garbage collection as per normal. It seems like D is a better fit for Julia than C in that regard.

On Friday, 12 December 2014 at 06:57:24 UTC, Laeeth Isharc wrote:
> On Wednesday, 7 May 2014 at 14:57:36 UTC, Chris wrote:
>> On Wednesday, 7 May 2014 at 12:05:10 UTC, bachmeier wrote:
>>> On Wednesday, 7 May 2014 at 09:16:01 UTC, Chris wrote:
>>>> On Tuesday, 6 May 2014 at 23:19:47 UTC, Mason McGill wrote:
>>>>> On Tuesday, 6 May 2014 at 11:28:21 UTC, Chris wrote:
>>>>>> Maybe it's time to think about a D interface to Julia. If Julia catches on within the scientific community, it would be good to have a foot in the door. Science quickly creates large code bases, unfortunately, so far it's mostly Python and Matlab which makes it hard to use the algorithms in real world applications.
>>>>>
>>>>> I've actually been working on just that, on and off for a few months now. Such a thing is kind of "anti-Julian", though, since one of Julia's main goals is to reduce or eliminate the need for mixed-language projects.
>>>>>
>>>>> However, with D, you can compile small shared libraries that can be automatically bound to your users' favorite dynamic runtimes (via compile-time reflection). I'm hoping this will be good for both D and Julia, allowing library developers to reach a broader audience, and library consumers greater flexibility.
>>>>>
>>>>> I'll post on the D "announce" thread when I have something working, and I'd definitely appreciate tests/bug-reports at that time!
>>>>
>>>> I was also thinking in the direction of enabling D to use existing Julia code seamlessly, so you can just call it from D (extern(J)), and maybe even efficiently compile it into binaries along with D code, as you would with extern(C) calls now.
>>>
>>> It's really easy to do that with R. There is a package RInside that makes it trivial to embed R in a C++ program, and it's not difficult to use with D.
>>
>> Would be cool if we had something like this for Julia (if it really catches on).
>
> I guess you can call D from Julia very easily via the C API and would just need to declare C calling convention in your D code.
>  It may be that with a combination of Julia and D one has the best of both  worlds - no compromise with speed and efficient resource use on the number crunching with a nice shell / Ipython notebook that is still pretty fast on the front end.
>
> Nicer would be a wrapper a la PyD that seamlessly translates between types.
>
> Then the other thing is to translate julia.h into D so that you can embed Julia.  That's a little work but not so hard.  More about how this works with C here:
>
> http://docs.julialang.org/en/release-0.3/manual/embedding/