[mercury-users] (the lack of) unique modes
Tomas By
tomas at research.nj.nec.com
Fri Nov 5 03:37:12 AEDT 1999
Hi,
There is a program I'm writing that uses a database, implemented in
the following way (the xxx's are self-defined types that only contain
simple things like ints and strings).
| :- type state ---> state(map(int,c),int,map(int,d),int).
|
| :- type c ---> c(bool,string,set(int),xxx).
|
| :- type d ---> d(bool,string,xxx,xxx,maybe(pair(string,a)),xxx).
|
| :- type a ---> a(map(int,xxx),map(string,set(int)),
| map(int,set(int)),map(int,set(int)),
| map(int,set(int)),int,int,set(string),int).
In general, there will be many items in the maps in the a's but not
that many a's and d's and only a few c's (typically just one).
The `state' is threaded through the code using the modes `in' and `out'.
After not very long the program gets very very slow, and it uses a lot
of memory. I assume this is because there is a lot of copying going on
and that using unique modes instead of `in' and `out' would be a good idea.
But the `LIMITATIONS' file says that unique modes are not fully
implemented, so my question is: would the functionality that unique
modes currently have help me and if not, how likely is it that you
will implement it fully?
/Tomas
--------------------------------------------------------------------------
mercury-users mailing list
post: mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe: Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------
More information about the users
mailing list