[mercury-users] discriminant types, generators and higher-order term+Darwin questions

[Fergus Henderson]

On 14-Jul-2003, Matthias Kretschmer <mccratch at gmx.net> wrote:
> And now I came up with two other questions:
> 
> 1. I was having a predicate using in solutions/2 which I wanted to use 
> with two different modes. So the compiler complained. I understand as 
> the language reference tells one, that higher order terms are only 
> allowed to have one mode. So a workaround would be to make something 
> like (pred(X::out) is nondet/multi :- myoldpred(X)).

Right.

> I was just 
> wondering if this should be changed in a way, or are there some design 
> decissions I am currently not aware of?

This has been discussed on a number of occaisions.  If you search
the mailing list archives, you should be able to find more detailed
discussions.  But the short story is as follows.

Firstly, there has not been much interest in supporting multi-moded
higher-order terms; this need does not seem very common, and if you do
need it you can always use a typeclass instead, or for that matter just
a tuple of singly-moded higher-order terms.
 
Secondly, there has however been a lot of interest in getting the compiler
to be able to infer the correct mode for a higher-order term, so that
the programmer does not need to supply explicit lambda expressions like
the one you wrote above in order to disambiguate.  In principle having
the compiler infer this would be a very good idea.  The problem with
this proposal is that it turns out to be very difficult to implement.

> 2. as one can read in README.MacOS there is currently no support for 
> dynamic libraries. I was wondering what is the current problem with 
> dynamic libraries on Darwin? One thing I guess is, that the 
> Boehm-Weiser garbage-collector used in some modified older version 
> isn't capable of supporting garbage-collection with dynamic libraries 
> on Darwin.

Right.

> If it is so, what modifications were applied to the garbage 
> collector, am I able to exchange it with some more modern version of 
> the garbage collector to be one step closer to dynamic libraries on OS 
> X?

There were no important changes made to the Boehm GC; the changes that
we have made have been (1) integrating it into our build environment
so that it gets built with the right CFLAGS, etc. and (2) a few minor
portability fixes (mainly for Windows), most of which have been folded
back into the main GC distribution by now.

Apart from that, I don't know of any in-principle reasons why shared
libraries would be problematic on MacOS, so supporting shared libraries
might be as simple as adding the appropriate case in the configure.in
file where it checks for "whether Mercury supports shared libraries on
this system".

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------