On 29 Jun 2009, at 13:28, mark richardson wrote:
I seem to recall some time ago reading a message from Torsten
Anders in
which he said that making multiple calls to Module.link is
'bad' (can't
remember the exact reason and at the moment can't locate the original
message either!)
The program I am developing dynamically loads constraints from
individual compiled functors (each constraint is contained in a
separate
.ozf file) which is ok initially because they are all linked with one
call to Module.link .
However, if I later want to include further constraints in the running
program (by further calls to Module.link) am I going to run the
risk of
problems such as Torsten mentioned? (whatever they were!)
Dear Mark,
Below please find a copy of the mail you mentioned. The problem I
mentioned with linking the same functor multiple times with
Module.link is that this results in multiple "instances" of stateful
data (cells etc) in the functor. Actually, this can also be useful,
the Oz documentation provides an example (Application Programming
tutorial, Sec. 3.5 User-defined Module Managers: http://www.mozart-
oz.org/documentation/apptut/node4.html#chapter.modman). Also, some
might argue that you are not supposed to link the same functor
multiple times anyway.
However, linking the same functor multiple times happens frequently
in my programs where I use multiple files in the OPI at the same
time. Sometimes I only feed one or two of them, but sometimes
multiple...
Anyway, an easy solution is to always replace Module.link with the
procedure ModuleLink defined below. I would suggest that this variant
becomes part of Mozart itself. However, as no-one reacted to my
previous suggestion I assume noone else has ran into this problem, so
I simply define this procedure in my OZRC :)
Best
Torsten
On 23 Jun 2009, at 13:30, Torsten Anders wrote:
Dear Mark,
Obviously at the moment I'm getting the error message that my cell
variables don't exist.
Please send us a code snippet that demonstrates your problem.
s there any way to be able to compile the functor without explicitly
passing the cell variables into the procedure definition?
I don't understand -- how do you want to access a cell without
explicitly passing it? What do you mean by "cell variable", its
content?
You can create cells in a functor, export them like any other data,
and also access and change their content within and outside the
functor.
There is only one thing to keep in mind. If you link your functor
with this cell multiple times using Module.link then you have
multiple independent copies of your cell. Below is an alternative
definition ModuleLink which makes sure there is always only a
single "instance" of your cell (more specifically, there is only a
single module manager created). IMHO, this should be the default
behaviour of Oz and multiple module managers should be special,
because multiple module managers are more stateful / less
declarative. Anyway, after this mail you find the alternative
definition.
Best
Torsten
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 {ModuleLink 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 {ModuleApply UFs}
{Map UFs fun {$ UF}
case UF of U#F then
{ModMan apply(url:U F $)}
else
{ModMan apply(UF $)}
end
end}
end
end
--
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
