[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