🚀 go-pugleaf

In article <1991Mar23.162203.305@csc.canterbury.ac.nz>,
fore057@csc.canterbury.ac.nz writes:
> o Users have plenty of control over memory allocation for code, stack, heap,
> and so on.

Gods below!  One of the major *FLAWS* in Turbo/PDC (and a lot of other
products too, to be fair), and it's called a feature!  One of the points
about Prolog systems is that memory management is the SYSTEM's problem,
not the programmer's.  The half-dozen or so Prolog systems I use from
time to time divide memory up using half-a-dozen or so different schemes.
(For example, one has a special memory area whose size I HAVE TO control
for numbers.  Ick!)  Dynamically resizing memory areas and moving them
around to fit may have been state of the art 20 years ago, but by now it
is "kindergarten" level.

Let me give you an example of what is WRONG with this approach.
As it happens, the system I was using was Turbo Prolog 2.something
There was one phase of the program which needed a lot of space in
area A, but very little in area B.  A later phase needed a lot of
space in area B, but very little in area A.  It turned out to be
impossible to find a single static allocation which was adequate
for both phases.  So I just couldn't run my program.  Why?  Because
of an entirely ARTIFICIAL restriction.  There was more than enough
space on the machine to do the job.  (In fact ALS Prolog just flew
through it.)  But because Turbo's implementors had seen fit to
unload part of *their* job onto the paying customer, the system was
not usable.

In operating systems such as MS-DOS, where several programs may
be sharing a single address space, it *is* reasonable to ask the
programmer to specify a limit on the *total* amount of memory to be
dedicated to any particular program.  But the size of individual
highly-system-specific partitions?  That is quite *unreasonable*.

> o There is plenty of on-line help, plus a very complete set of manuals.

Hm.  Presumably PDC have rewritten the manuals completely.  I found the
Turbo 2.something manuals incomplete and confusing.

-- 
Seen from an MVS perspective, UNIX and MS-DOS are hard to tell apart.