[mercury-users] Native garbage collector for Mercury

[Peter Ludemann]

On Fri, 11 Sep 1998 22:29:00 PDT, Fergus Henderson <fjh at cs.mu.OZ.AU>

> Well, one thing that a good system implementation language should have is
> support for concurrency.

Not true.  I worked on the DMS/100 (hard) real-time telephone switch
back in the late 70s (it could handle 100 calls-per-second and 100K
telephone lines, all with a 1 MIPS single processor plus a lot of Z80s
as peripheral controllers).  The implementation language, an extended
Pascal, head *no* support for concurrency (there was some support for
process- and module-based data sharing, which wasn't often needed).
This was very good, because we ended up defining 3 kinds of
inter-process communication, of which 2 were seldom used.  (This is
probably one of C's advantages: no support for concurrency or even
I/O, but libraries that do provide such things [OK, not concurrency].)
[BTW, for you hard-real-time fans, very little of the telephone system
actually used the hard-real-time facilities, beyond using timeouts as
an indication of system (hardware/software) failure.]

It is also *not* true, as somebody earlier claimed, that a lot of O/S
code is low-level and needs to be very fast.  I would estimate that
less than 1% of an operating system needs to be super-fast; perhaps
10% needs to be fast; and the rest could probably be done with
interpreted languages (BTW, Cygnus has just announced a front-end to
gcc for Java).

Returning from topic drift ... I think that one of the problems with
the Japanese 5th generation project was that they worked a limited LP
language, because they thought that full LP would be too inefficient
for their OS work.

- peter ludemann