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^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 <[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. >>>> >>> >>> >
