[mercury-users] higher order modes

[Fergus Henderson]

On 10-Sep-2000, Michael Day <mcda at students.cs.mu.oz.au> wrote:
> 
> If I try to return a det predicate where a semidet one is expected I get a
> nasty and rather unobvious mode error. This can be avoided by promoting
> (or demoting?) the predicate explicitly with a lambda expression:
> 
> 	SemiThing = (pred(...) :- DetThing)
> 
> Is there any reason the compiler can't do this by itself?

This conversion is needed because closures of different determinism
are represented differently -- the code address in the closure has
different calling conventions depending on the determinism.

Would you want the compiler to do the same conversion implicitly
if the argument (or return value) was a list of predicates, rather
than just a single predicate?

To those who would answer yes, I would say that having the compiler
perform implicit conversions that cost O(N) is counter to our aim
of having a simple performance model for the language.  Furthermore,
implementing this would add a quite significant amount of complexity
to the compiler.

To those who would answer no, but who still want the compiler to
perform the conversion in the case where the argument is just a single
predicate, I would say that this is inconsistent, and that the drawbacks
of this inconsisistency would most likely outweigh any benefits that might
be obtained from doing such conversions implicitly.

Another alternative would be to represent closures of all determinisms
in the same way, so that no representation conversion would be needed [*].
Then it would be OK for the mode checker to allow such code.
However, this alternative would involve a small performance cost,
which would be contrary to the goal of ensuring that users don't pay for
features that they don't use.  It might perhaps also complicate
interoperation with other languages that support closures.
So, although I could live with this alternative, I think overall the
net effect would not be much of an improvement over the status quo,
and possibly no net improvement or even a slight detrimental effect.
So I think we have more important things to focus on at this time.

Footnotes
---------
[*] One way of ensuring that all closures had compatible representations
would be to store not one but three code addresses in each closure,
one for each different calling convention [model_det, model_semi,
and model_non, for those familiar with the compiler internals].
For a model_non closure, the other two code addresses could be null,
but for a model_det closure, the other two code addresses would
point to code that had a model_semi or model_non calling convention
and which just called the model_det procedure.  This would add two
words to each closure, and would also increase code size and
compilation time slightly, due to the wrapper code needed for
every model_det and model_semi closure.

Alternatively, to avoid increasing the dynamic memory requirements,
the code addresses could be stored in the closure_layout field.  This
would actually require one word less per closure than the current
representation, but would require an extra indirection for each call
to a closure, and would worsen locality (the extra indirection could
easily cause a cache miss).

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- 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
--------------------------------------------------------------------------