[mercury-users] as pattern and mostly_xxx

[Fergus Henderson]

On 13-Oct-1998, Martin Stein <ms40 at inf.tu-dresden.de> wrote:
> 
> 1. I wonder but I can't find anything like the as-pattern in Haskell. It would
> be very convenient to write something like
>     pred(T is node(Tr,K,V,Tl),...)
> Or missed I something?

Just use `=', i.e. instead of 

	p(T is node(Tr,K, V, Tl), ...) :- ...

use

	p(T, ...) :- T = node(Tr,K, V, Tl), ...

(Alternatively, you could just duplicate the pattern, i.e. replace
each occurrence of `T' with `node(Tr, K, V, Tl)' -- the compiler's
common subexpression elimination will detect this, I think, and
thus generate the same code anyway.)

> Writing 'T is ...' as a goal creates a new node. Is that right? (So that would
> be less efficient than the as-pattern.)

Using `=' is no less efficient than using `as-patterns' would be.

> 2. I ran into problems using then random module. The compiler itself couldn't
> deduce the modes for predicates using a type like xx(random__supply)
> and the compiler didn't accept my modes, too.
> Due to the manual that arose because of not yet implemented features.
> Or am I wrong?

There is a known limitation of mode inference in versions 0.7.3 and before
that they are completely unable to infer `mostly_unique' modes, which are
used in the random module.  This is fixed in the latest development version.

So, if you're just passing values of type random__supply around,
then if you give the right modes it should work fine, and with the
latest development version the compiler should be able to infer the modes too.

However, if you are storing values of type random__supply inside other
data structures, then there is a problem.  In the current
implementation, unique modes (and mostly_unique modes) can't handle that.
This will hopefully be fixed soon, but not in the next release.

Furthermore, if you are using polymorphic types from the standard
library such as `set(random__supply)', then there is another problem:
the standard library predicates for manipulating sets and other
polymorphic data types generally only have in/out modes, not unique or
mostly_unique modes.  Ideally I guess we'd have some kind of polymorphically
unique modes, but that is still a research issue at this stage.

> (It's only a question. I'm using my
> own random.m with in and out instead, that works.)

This is probably the best solution, at least in the near future.

> BTW Is there any support for a Mercury emacs-mode?

Well, the `mtags' script has support for Emacs format TAGS files...

-- 
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.