Thank you for the link. I guess an intermediate layer of C application should be written for specific function calls, parameter passing and result set accumulation or manipulation. From Scala compiler (and executor) this application can be accessed through Native Interfaces (JNA4Scala !!). I am going to explore the documentation to see how GC works (important) and how DataFrames / DataArrays are stored in cache when called from Scala through Native Interfaces (JNA4Scala !).
Please provide any other important links. On Thursday, October 22, 2015 at 12:42:07 PM UTC-7, Spencer Russell wrote: > > 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://www.google.com/url?q=http%3A%2F%2Fdocs.julialang.org%2Fen%2Frelease-0.4%2Fmanual%2Fembedding%2F&sa=D&sntz=1&usg=AFQjCNGrYENY-41A9C63OkBCFP_2gWYB2A> > > -s > > On Oct 22, 2015, at 3:07 PM, ssarkaray...@gmail.com <javascript:> 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, <ssarkaray...@gmail.com> 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^3end >>> >>> 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 < >>>> ste...@karpinski.org> wrote: >>>> >>>>> On Tue, Oct 20, 2015 at 7:00 PM, Brendan Tracey <tracey....@gmail.com> >>>>> 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. >>>>> >>>> >>>> >> >
