Julia has a well-developed C API, so you can embed it inside other applications. Info on using it is here: http://docs.julialang.org/en/release-0.4/manual/embedding/ <http://docs.julialang.org/en/release-0.4/manual/embedding/>
-s > On Oct 22, 2015, at 3:07 PM, [email protected] wrote: > > I found that you are one of the core developers of Julia language. Could you > please explain how Julia compiler and executor can be called > through APIs ? Are there any documentations for APIs. > Is it possible to call Julia compiler and executor through programming > interfaces from Scala compiler / executor ? I am > trying to understand broad strategy for possible implementation of ScalaJulia > language. > > On Wednesday, October 21, 2015 at 12:41:49 PM UTC-7, Stefan Karpinski wrote: > Excellent idea. You should make a PR against the Scala GitHub repo and see > how it goes. > > On Wed, Oct 21, 2015 at 3:31 PM, <[email protected] <javascript:>> wrote: > How is the idea that any function defined with Julia tag gets into a first > class object with name Julia in a combined ScalaJulia language : > > Julia function sphere_vol(r) > # julia allows Unicode names > <http://docs.julialang.org/en/latest/manual/unicode-input/> (in UTF-8 > encoding) > # so either "pi" or the symbol π can be used > return 4/3*pi*r^3 > end > is translated into ScalaJulia language as: > > object Julia { > > def sphere_vol(r : Int) { > > return ( 4/3*pi*r^3 ) > > } > } > > > Object Julia will get all first level functions defined in Julia syntax. > This is the simplest way to encapsulate > Julia functions and inherit in other Scala objects or classes in ScalaJulia > language. > > This will preserve simplicity and performance of Julia functions. > > SS > > > On Wednesday, October 21, 2015 at 10:00:25 AM UTC-7, Tom Breloff wrote: > I think this discussion shows complementary definitions of traits: > verb-based traits: a type agrees to implement all the verbs appropriate to > the given "verb trait" > noun-based traits: a type agrees to contain certain underlying data (and thus > the getter/setter verbs could be implicitly defined for those fields) > Whatever the final implementation of traits in Julia, I think keeping in mind > this distinction could be helpful. > > On Wed, Oct 21, 2015 at 12:42 PM, Stefan Karpinski <[email protected] <>> > wrote: > On Tue, Oct 20, 2015 at 7:00 PM, Brendan Tracey <[email protected] <>> > wrote: > > > Above, a relatively simple macro can replace all the "Type..." with the > > fields of the composed types, applying multiple inheritance of the > > structures without the baggage required in classic OOP. Then you can > > compose your type from other types, but without having to write > > "unicycle.wheel.radius"... you can just write "unicycle.radius". > > As Stefan mentioned, Go is not traditional OO. This "composition-based" > approach is part of Go's OO approach. In go, a type can have named fields of > different types (like most OO languages), but also has "embedding". For > example, if one declared > > type Unicycle struct { > Wheel > Frame > Seat > } > > then you could access the individual fields directly. So, if "u' is of type > Unicycle, then you could access/set u.Cushiness directly. Similarly, if the > embedded types had methods, i.e. frame.Color(), they can be called directly > through unicycle, u.Color(). This is similar to, but distinct from, > inheritance (the difference is that the Unicycle type doesn't actually have > these fields, just the ability to call them easily, which is significant > because of interfaces). In the case of clashes, the program must specify > which is meant, so if both Seat and Frame had a Color() method, the user > would have to specify u.Frame.Color vs. u.Seat.Color. In Go, this is handled > by the compiler, and would need to be handled somewhere in the Julia > runtime/REPL. It's a very nice paradigm, but would have to be made to fit > within the broader Julia context. > > I do like this approach to composition/delegation, but it requires > automatically adding a lot of methods to the delegator, i.e. Unicycle in > this example, from all of its components, which feels kind of nasty and > dangerous, especially since we allow dynamic addition of methods > after-the-fact. In other words, you might add a method to Wheel, Frame or > Seat at any time, which would presumably then also apply to Unicycle objects, > potentially with unexpected consequences. It would be nice if the delegation > was more limited than that. Go doesn't have this problem since you can't > dynamically add methods – everything is known at compile time. > >
