[mercury-users] existential constraints

Michael Day mcda at students.cs.mu.oz.au
Wed Jul 26 14:04:54 AEST 2000

> The two mode declarations that I have marked `[wrong]'
> don't make sense for their respective type declarations,
> since they give an existentially typed argument an input mode,
> which is not possible, at least not for Mercury's current operational
> semantics.  Think about it: if the argument is existentially typed, this
> means that the _callee_ determines the type, but for the argument to be
> input, the _caller_ must provide a value for that type (*before* calling
> the callee).

The compiler didn't seem to complain, the compiler in question being

> Actually at one point we considered allowing what I think we called
> "implied quantification", by analogy to implied modes: if in some
> mode of a procedure an existentially typed argument has an input mode,
> then treat it as universally quantified for that mode.  However, that
> complicated things, was tricky to implement (if indeed it is possible
> -- I haven't really analyzed it in depth), and we didn't see any
> compelling need for it.  So we have basically shelved that one.  But
> if you have some particular application where you think you might need
> this, please let us know.

This is rather what I was thinking of.

> It would be nicer if the syntax was just "new functor" rather than
> "'new functor'", and we might make that change at some time (it's a
> fairly low priority item).  But the need to explicitly annotate
> constructions of existentially quantified data types with "new" will
> not be going away any time soon.

Oh I see. Is this something that will one day change (post 1.0?) or must
it remain for theoretical reasons beyond my ken?


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