This seems to be a design based largely on npm. The idea of modules (and packages) being unnamed internally is appealing, largely for the prospect of it being possible to rename packages without breaking code that uses them although I'm not certain this is realistic.
I'm not sold on the idea that it makes sense to load multiple versions of packages. There are some major issues: *Generic functions.* What happens when two different versions of a package both introduce separate generic function that other packages are supposed to share? One of the most confusing situations I see people encounter is when they've reloaded some code that defines a type and have a generic function that dispatches the old version of that type and they try to call the function on the new version of the type. The dispatch doesn't work, of course, but it looks like it should. Very confusing. This seems to be intentionally introducing a far worse form of that. It's possible that a coherent story can be told about how to deal with this, but without that story this seems pretty hard to swallow. *Shared system libraries.* What do you do when two different versions of a package want to load different versions of system libraries? In theory dlopen can do this but in practice it does not work well at all. JavaScript doesn't have to deal with this so npm can just ignore the issue. *Code generation.* Julia is already a bit of a beast when it comes to the amount of code that is generated. This makes that N times worse, for some unknown and potentially fairly large N. On Sun, Dec 20, 2015 at 10:05 AM, Tom Breloff <[email protected]> wrote: > My reaction is the same as Tim Holy's. While I agree there are aspects of > Julia's modules which are not perfect, it's not clear at all how your > package changes the workflow. In fact, I don't understand anything about > your package. Could you please try to write up the design thoughts behind > what you are doing, so that we can understand the high level concepts that > you are attempting? > > On Sun, Dec 20, 2015 at 6:24 AM, Tim Holy <[email protected]> wrote: > >> After reading your README example, I'm still left wondering how one works >> with >> Kip, or how it fixes the problems you're describing. To me it's not at all >> obvious how your example "illustrates" the statements you make in the >> prose. >> You might consider explaining the meaning of the various arguments to >> @require, what an "index" file is and what its format should be, and >> exactly >> what the call to the emit function is supposed to demonstrate. >> >> Best, >> --Tim >> >> On Saturday, December 19, 2015 11:26:53 PM Jake Rosoman wrote: >> > I forgot to actually link to the project < >> https://github.com/jkroso/Kip.jl> >> > >> > On Sunday, December 20, 2015 at 8:25:04 PM UTC+13, Jake Rosoman wrote: >> > > Julia's module system is the one part of it I feel confident enough >> to say >> > > is bad. It can't handle several versions of the same package. Is hard >> (or >> > > impossible?) to depend on packages that aren't in the registry and >> hard to >> > > add (controversial) things to the registry. I also find it ugly and >> hard >> > > to >> > > use but now I'm getting into opinions so I'll stop. >> > > >> > > Kip solves all these problems and works fine alongside Julia's current >> > > module system so you can try it out now. I hope that eventually we can >> > > replace Julia's module system if people generally agree that it's >> worth >> > > doing. I've created a poll to measure the communities opinion >> > > <http://tally.tl/3002Y> and you can change your vote at any time so >> feel >> > > free to say no now but follow the discussion. >> >> >
