Re: [julia-users] Re: associative property of export/include/import?
Hello colleauges, On Wednesday, July 23, 2014 6:18:03 PM UTC+2, Stefan Karpinski wrote: On Wed, Jul 23, 2014 at 6:06 AM, Andreas Lobinger lobi...@gmail.com javascript: wrote: In principle i agree, everything that is defined in the Modules is usable regarding its own namespace. But then, why do we have the export of functions? It's not even needed... If you strictly prefix all functions by their module everything will be alright, but what in mixed environments? You can just do `import Gadfly` and `import Gtk` and then use everything via prefixes like `Gadfly.plot`. I suspect this will be unpopular for interactive work, however. The point i'm trying to make is: The current situation - not merging the functions/methods - creates a dependency between Modules/Packages. Is this the intended work style? Merging functions is definitely not a good solution. In issue #4345 https://github.com/JuliaLang/julia/issues/4345 I proposed that clashing names be dropped entirely, forcing the programmer to pick which name they meant explicitly. That would make the order that using statements occur insignificant, at least in this regard. I read the #4345 and find also there some messages in favour of merging. I'm not really into the terminology what is a method and what is a function, i tried to make my point from the perspective of usability (and ease of development). btw (side effects)... lobi@maroon:~/juliarepo$ ../julia/julia _ _ _ _(_)_ | A fresh approach to technical computing (_) | (_) (_)| Documentation: http://docs.julialang.org _ _ _| |_ __ _ | Type help() to list help topics | | | | | | |/ _` | | | | |_| | | | (_| | | Version 0.3.0-rc1+116 (2014-07-21 15:59 UTC) _/ |\__'_|_|_|\__'_| | Commit e75595f* (3 days old master) |__/ | i686-linux-gnu julia using Gtk julia type bVector b::Int32 end julia function draw(v::bVector) print(v); end draw (generic function with 1 method) julia lobi@maroon:~/juliarepo$ ../julia/julia _ _ _ _(_)_ | A fresh approach to technical computing (_) | (_) (_)| Documentation: http://docs.julialang.org _ _ _| |_ __ _ | Type help() to list help topics | | | | | | |/ _` | | | | |_| | | | (_| | | Version 0.3.0-rc1+116 (2014-07-21 15:59 UTC) _/ |\__'_|_|_|\__'_| | Commit e75595f* (3 days old master) |__/ | i686-linux-gnu julia using Gtk julia methods(draw) # 3 methods for generic function draw: draw(redraw::Function,widget::GtkCanvas) at /home/lobi/.julia/v0.3/Gtk/src/cairo.jl:56 draw(widget::GtkCanvas) at /home/lobi/.julia/v0.3/Gtk/src/cairo.jl:61 draw(widget::GtkCanvas,immediate::Bool) at /home/lobi/.julia/v0.3/Gtk/src/cairo.jl:61 julia type bVector b::Int32 end julia function draw(v::bVector) print(v); end ERROR: error in method definition: function Gtk.draw must be explicitly imported to be extended ... I find the situation of developers of modules/packages to organize which english words (maybe unicode can help here...) to use in exported functions, well, complicated, because the 'good ones' are already taken (plot, draw, paint, render, update, show, calc, derive, optimize etc.) and only the non-obvious verbs are 'free' (unless taken). And for some time i was under the impression, that multiple dispatch helps here, because there would be a draw(::thisType) and a draw(::thatType) and a draw(::somethingCompletelyDifferentType) and the propability that types are named conflicting i rate lower. There might be something complicated in the technical background, but from a commandline perspective: i can merge functions in the same module (Main), why can't i across modules?
Re: [julia-users] Re: associative property of export/include/import?
Hello collague, On Tuesday, July 22, 2014 4:25:46 PM UTC+2, Mauro wrote: I agree that there should be some means of resolving conflicts (by warning, by precedence) but just dropping a whole set of methods because they conincidentially have the same name AND at the same time advertising multiple dispatch in julia doesn't fit for me. Multiple dispatch would still work and no methods are dropped, you would just need to fully qualify the generic function, like e.g. `Gadfly.plot`, or you could do `plot = Gadfly.plot` to get the one generic function you want into the global namespace. I think this would be less confusing than the order of `using` be significant. In principle i agree, everything that is defined in the Modules is usable regarding its own namespace. But then, why do we have the export of functions? It's not even needed... If you strictly prefix all functions by their module everything will be alright, but what in mixed environments? The point i'm trying to make is: The current situation - not merging the functions/methods - creates a dependency between Modules/Packages. Is this the intended work style?
Re: [julia-users] Re: associative property of export/include/import?
There is another option, which won’t necessarily work for plot but might resolve many other issues (and is frequently used on functions like push!): make both modules import a common function to extend. What took me a while to understand in this context, is the distinction between a *function* and a *method* - Julia is one of very few contexts I’ve come across where the difference between these two actually makes a big difference. To brush up: - A *function* is a first-class citizen in the language. It has a qualified name (e.g. Gadfly.plot) and can, if imported, be referred to via the last part of the qualified name, which I will call the “short name” (e.g. plot). There can be many functions with the same short name, as long as they’re defined in different modules. - A *method* is (simplifying a bit) a function and a tuple of types. The function is basically just a way to group methods doing similar things, and the type tuple is what decides what code is run (multiple dispatch). One function can have many methods, but a method can only belong to one function. Additionally, no two methods belonging to the same function can have the same argument types. When you say function dostuff() ... end in your code, what you’re *really* saying is this: If there is a *function* dostuff in the current context, extend it with a *method* that takes the arguments of the following types: (). If there is *no* such function, define one for me and then add the method. The confusing thing when doing using Gadfly and using Gtk (in some order) is that since there isn’t a function Base.plot for them to import, they must both define their own. And even though the two plot methods have the same short name, they’re really not the same function, and so their methods have nothing to do with eachother. (The fact that we associate them with each other is just because they happen to have the same short name, which only really matters to us humans reading the code anyway…) Thus, to make it possible for several modules to extend the same function with new methods, *the function must be defined outside all of the modules*, so they can all import it and extend it, rather than define a new one. As mentioned above, many packages import e.g. Base.push! to be able to add methods to it, and since they all extend Base.push! rather than defining their own methods, the order in which you use them (with using) doesn’t matter (at least as long as they don’t have any argument type conflicts). Personally, I think it’s a *good* thing that Julia doesn’t do too much magic stuff in situations like this. Plotting is something where the API will look quite similar regardless of which package you’re using, and it would be hopeless to try to merge the plot functions from e.g. PyPlot and Winston… // T On Wednesday, July 23, 2014 3:06:03 PM UTC+2, Andreas Lobinger wrote: Hello collague, On Tuesday, July 22, 2014 4:25:46 PM UTC+2, Mauro wrote: I agree that there should be some means of resolving conflicts (by warning, by precedence) but just dropping a whole set of methods because they conincidentially have the same name AND at the same time advertising multiple dispatch in julia doesn't fit for me. Multiple dispatch would still work and no methods are dropped, you would just need to fully qualify the generic function, like e.g. `Gadfly.plot`, or you could do `plot = Gadfly.plot` to get the one generic function you want into the global namespace. I think this would be less confusing than the order of `using` be significant. In principle i agree, everything that is defined in the Modules is usable regarding its own namespace. But then, why do we have the export of functions? It's not even needed... If you strictly prefix all functions by their module everything will be alright, but what in mixed environments? The point i'm trying to make is: The current situation - not merging the functions/methods - creates a dependency between Modules/Packages. Is this the intended work style?
Re: [julia-users] Re: associative property of export/include/import?
On Wed, Jul 23, 2014 at 6:06 AM, Andreas Lobinger lobing...@gmail.com wrote: In principle i agree, everything that is defined in the Modules is usable regarding its own namespace. But then, why do we have the export of functions? It's not even needed... If you strictly prefix all functions by their module everything will be alright, but what in mixed environments? You can just do `import Gadfly` and `import Gtk` and then use everything via prefixes like `Gadfly.plot`. I suspect this will be unpopular for interactive work, however. The point i'm trying to make is: The current situation - not merging the functions/methods - creates a dependency between Modules/Packages. Is this the intended work style? Merging functions is definitely not a good solution. In issue #4345 https://github.com/JuliaLang/julia/issues/4345 I proposed that clashing names be dropped entirely, forcing the programmer to pick which name they meant explicitly. That would make the order that using statements occur insignificant, at least in this regard.
Re: [julia-users] Re: associative property of export/include/import?
I agree that there should be some means of resolving conflicts (by warning, by precedence) but just dropping a whole set of methods because they conincidentially have the same name AND at the same time advertising multiple dispatch in julia doesn't fit for me. Multiple dispatch would still work and no methods are dropped, you would just need to fully qualify the generic function, like e.g. `Gadfly.plot`, or you could do `plot = Gadfly.plot` to get the one generic function you want into the global namespace. I think this would be less confusing than the order of `using` be significant.
