Dear Raphael,
Thanks for your quick reply.
First I would like to clarify that I do not propose removing any
existing definition (they have their applications as I mentioned
before, and removing them might also break exiting code). Instead, I
only suggest *adding two new procedure* that are alternatives to
Module.link/Module.apply.
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.
I don't understand. Also with the current definition of Module.link
already linked functors do not disappear if you link any new functors
(luckily :), they remain in memory only they are scattered across
multiple module managers. On the contrary, if with with the current
definition of Module.link you link the same functor multiple times
then this results in multiple module copies.
Also, please note that the two new Link2/Apply2 procedures would
behave basically like the linking between functors already does,
which also uses only a single module manager, even if the same
functor is imported by multiple other functors. Why should something
that is good between compiled functors be problematic when linking
functors in the OPI?
Best
Torsten
On 30 Jun 2009, at 13:00, Raphael Collet wrote:
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 mozart-
[email protected]
http://www.mozart-oz.org/mailman/listinfo/mozart-users
<ATT00001.txt>
_________________________________________________________________________________
mozart-users mailing list
[email protected]
http://www.mozart-oz.org/mailman/listinfo/mozart-users
