Am I right in thinking that the issues you have with function call overloading are equivalent to those involved with multiple inheritance? In the sense that overloading function application effectively makes an array (for example) a member of both AbstractArray and Callable, which will create ambiguities in functions which dispatch on both.
In that case, it may be best to separate these two issues. So you can overload x(y) and it will work when you directly call x, but x::Callablewill fail. Then you declare x<:Callable, and the multiple inheritance part of the type system kicks in to help you resolve ambiguities. Another option (in terms of multiple inheritance) might be to have some kind of priority for parents: "x is an AbstractArray first, and a Callablesecond", i.e. if there's any ambiguity dispatch as AbstractArray. In the sense it's the same as the way children are prioritised over parents already. This would would make multiple inheritance very low-effort at the user level, but the implicit-ness might end up being a bad idea if it makes things hard to reason about (I don't know if it will). On 8 May 2014 07:47, Stefan Karpinski <stefan.karpin...@gmail.com> wrote: > Thanks for reporting these first impressions – I find this sort of thing > really helpful and interesting. We did try really hard to make the learning > curve for Julia very gentle, the idea being that people who don't care > about fancy language features should be able to use it productively too and > learn about new feature only when they become useful. It's nice that this > comes across. > > The business of function application and array indexing being different > has come up a number of times recently – someone mentioned it to me in > comparison with J/APL programming. And obviously in Matlab they're the same > syntax, but since neither functions nor arrays can be used in a higher > order fashion, that hardly matters. It makes me wonder about a design where > they're the same thing and what problems that would solve and introduce. It > would require some degree of overloading of function application syntax, > which we've contemplated but don't do. In the meantime, we can pretty > easily leverage multiple dispatch to make map(a, v) work as desired when a > is an array. Which highlights one obvious issue: in a language with > multiple dispatch, if lots of things are callable as functions, it makes a > lot of higher order programming signatures pretty ambiguous. Map is easy – > the first argument is function-like – but other functions that have higher > order and non-higher-order variants require more thought. Is it better to > make function application and array indexing the same thing and have that > similarity fall out everywhere but also force users to deal with that > ambiguity when writing method signatures, or is it better to go through the > standard library and make sure that every place where a function could be > used in a way that an array would also make sense, we allow it? I'm > honestly not sure. > > On May 6, 2014, at 11:15 PM, Abram Demski <abramdem...@gmail.com> wrote: > > Hi all! > > I've been using Julia for a little over a month now, and I thought it > would be fun/informative to write a little post about my experience. > > I'm mostly a Common Lisp guy. I write AI code in an academic setting. > However, I recently became enthusiastic about Clojure and was trying to > start a project in that. > > Indecisive as usual, I continued poking around looking for the best > programming language to do the project in, even as I became fairly > committed to doing it in Clojure. > > I had heard about Julia some time ago (looked at it very briefly), but > looked at it a second time when a friend mentioned it on twitter earlier > this year. > > Looking at it again, I realized that: > > 1) Julia is "essentially a Lisp", IE, it is homoiconic (despite not > appearing so) and has the metaprogramming capabilities I am used to. (I > don't need these often, but if a language lacks it, I feel like I'm missing > an essential tool.) > 2) Julia's type system and multiple dispatch capabilities give me much of > what I liked about Clojure's multimethods and protocols. > 3) Julia is significantly faster (at least for many things). > > I decided to start hacking out my project in Julia, abandoning the Clojure > code I had started. > > After using it for a bit, I feel like it's been much easier to pick up > what I need to know than it was with Clojure. Both Julia and Clojure have > the deep, elegant stuff I like in a programming language; however, it seems > like Clojure creates a rich, interlocking set of concepts which you *must* > learn > in order to write very much code, whereas Julia has a gentle learning > curve, facilitating "normal" programming and allowing the user to learn the > deeper features as they become useful. At least, that's been my feeling. > > Monkeying around with the metaprogramming *has* taught me that it's a > *bit* less convenient than Lisp. Thinking about expr.head and expr.args > is not as intuitive as composing expressions as lists, I think. It's not a > big obstacle, though. > > I've also found it a bit annoying that array access is not the same as > function application, again a feature of Clojure. Being able to treat > arrays and dictionaries as functions is convenient for certain higher-order > functions like map. > > Overall, although I admit I'm judging Julia by Lisp/Clojure standards, it > comes out rather favorably. :) > > -- > Abram Demski > Blog: http://lo-tho.blogspot.com/ > Leave anonymous feedback: http://www.admonymous.com/abramdemski > >
