[mercury-users] Native garbage collector for Mercury

[Fergus Henderson]

On 11-Sep-1998, Ralph Becket <rwab1 at cam.sri.com> wrote:
> 
> > Moreover, what does Mercury lack besides real-time garbage collection to
> > serve as the ultimate SIL?
> 
> A good deal of OS code is very low-level.  It needs to be small and
> tight.  Conventional wisdom has it that a language with a close
> relationship to the bare metal is a good thing to use here.  Mercury
> (bar its C interface) is not like this.

With a suitable programming style, Mercury can actually be very close
to the bare metal.  In some respects, it's even better than C in this area.
Machines have multiple registers, but C doesn't let you return multiple
arguments; unlike C, Mercury has output modes, which let you return
multiple values in registers.  Tail calls in Mercury compile to jumps,
whereas in C there's no easy way to get a cross-function jump.

Note that Mercury is quite different from Prolog with regard to
"close to the metal" programming.  Explicit determinism declarations
mean that you don't get unexpected choice point creation.
The strong mode system means that the compiler doesn't have to
insert dereferencing code in front of variable accesses.
Unique modes give you destructive update.  And Mercury has
support for arrays and even pointers (see the `store' module in
the standard library).  These points all make Mercury much much better
than Prolog for doing "close to the metal" programming.

Of course, you don't *have* to write Mercury code in a "close to the metal"
style.  Like C++, Mercury aims to be a wide-spectrum language: one where
you can write both low-level code and high-level code in the same language.

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