Dear Torsten, Well, there would be good and less good consequences ;-)
Many applications do not need a "permanent" module manager, because all the modules are linked once at application startup. Moreover, many functors we write are stateless, so that applying them more than once does not hurt. The functors used by the distributed search engine must be stateless, for instance. Having a permanent module manager has a non-negligible drawback: all linked modules remain in memory forever. This is not good as a "default" behavior. That's why in my opinion, we should stick with the current solution. In the case were you want to keep track of linked modules, I suggest to do it explicitly with a module manager object. It's very easy, the code you just wrote will do the job. I think it is also safer, because you can use it only for the modules that need this behavior. Cheers, raph On Tue, Jun 30, 2009 at 1:35 PM, Torsten Anders < [email protected]> wrote: > Dear Raphael, > > So, this leaves the question: would it not be a good idea to have build-in > easy-to-use module linking facilities that (i) would indeed remember the > functors it linked before, and (ii) would be as easy to use as Module.link. > In other words, should we not add something like the definitions below to > the Module functor of Mozart itself. Would an addition as minor as this need > an MEP? > > Thank you! > > > local > ModMan = {New Module.manager init} > in > /** %% ModuleLink is like Module.link except that multiple calls > of ModuleLink share the same module manager (and don't create new > managers as Module.link does). For instance, when ModuleLink links > multiple functors which refer to a stateful datum in some functor, > then all refer to the same datum instance. By constrast, linking > with Module.link results into multiple stateful datum instances. > %% */ > fun {Link2 UrlVs} > {Map UrlVs fun {$ Url} > {ModMan link(url:Url $)} > end} > end > /** %% ModuleApply is like Moduel.apply expect that it always > uses the same module manager (cf. ModuleLink). > %% */ > fun {Apply2 UFs} > {Map UFs fun {$ UF} > case UF of U#F then > {ModMan apply(url:U F $)} > else > {ModMan apply(UF $)} > end > end} > end > end > > > > > Best > Torsten > > > On 29 Jun 2009, Raphael Collet wrote: > > You are completely right. I was confused by the definition, too. The > point > of Module.link is to handle properly modules that have coreferences or > cycles in their imports. > > If you want to link every functor at most once, you should create a module > manager, and always link with that module manager. > > > > > > On Mon, Jun 29, 2009 at 6:42 PM, Torsten Anders <torsten.anders at > plymouth.ac.uk> wrote: > > On 29 Jun 2009, at 14:08, Raphael Collet wrote: > > > > Module.link takes a URL as an argument, and guarantees that several calls > > to it with the same URL will only apply the corresponding functor once. > So, > > provided that you don't refer to a given functor with distinct URLs, it > will > > never be applied more than once with Module.link. > > > > > > It appears there is some misunderstanding here. The behaviour you > describe > > only happens if the same functor is linked multiple times in a single > call > > of Module.link -- which would indeed be a strange thing to do. > Module.link > > always creates a new module manager ( > > http://www.mozart-oz.org/documentation/system/node7.html#chapter.module > ), > > and a new module manager has no idea what functors have been linked by > other > > module managers. > > > > As a result, linking the same functor multiple times with *multiple calls > > of Module.link* will result in quasi multiple instances of its stateful > > data. That this is indeed the case is exemplified by the tutorial example > I > > mentioned in my previous mail. This behaviour is also useful if the > > definition of the functor changed. However, if this behaviour is not > > intended then it results in bugs that are *very* hard to find. > > > > What I was suggesting is a definition of Module.link/Module.apply, where > > multiple calls of these procedures always use the same module manager > (see > > my previous mail for its definition). This approach would indeed result > in > > the behaviour you described. I suggest to have both versions as part of > > Mozart itself. > > > > Best > > Torsten > > > -- > Torsten Anders > Interdisciplinary Centre for Computer Music Research > University of Plymouth > Office: +44-1752-586219 > Private: +44-1752-558917 > http://strasheela.sourceforge.net > http://www.torsten-anders.de > > > > > > > > _________________________________________________________________________________ > mozart-users mailing list > [email protected] > http://www.mozart-oz.org/mailman/listinfo/mozart-users >
_________________________________________________________________________________ mozart-users mailing list [email protected] http://www.mozart-oz.org/mailman/listinfo/mozart-users
