Hi,
Thanks for the quick response. I hadn't realised you had mentioned this
subject in the message below, I was thinking of a post you made some
months ago.
I must be having a difficult week :+)
But anyway, if I'm not misunderstanding this, the problem you say is
with multiple links to the SAME functor? Not multiple calls to
Module.link where each call links a different functor?
Mark
Torsten Anders wrote:
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
--
Mark Richardson
Research Assistant
University of Teesside, UK
[email protected]
[email protected]
[email protected]
_________________________________________________________________________________
mozart-users mailing list
[email protected]
http://www.mozart-oz.org/mailman/listinfo/mozart-users
