Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!comp.vuw.ac.nz!waikato.ac.nz!canterbury!fore057
From: fore057@csc.canterbury.ac.nz
Newsgroups: comp.lang.prolog
Subject: Re: Environments
Message-ID: <1991Mar25.220652.319@csc.canterbury.ac.nz>
Date: 25 Mar 91 10:06:51 GMT
References: <1991Mar23.162203.305@csc.canterbury.ac.nz> <5044@goanna.cs.rmit.oz.au>
Organization: University of Canterbury, Christchurch, New Zealand
Lines: 26

In article <5044@goanna.cs.rmit.oz.au>, ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
> 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.

Was it stack space that was the problem?  I'd be interested to hear what the
PDC would recommend for this situation - are you there Per?

A solution may have been to use the check_determ instruction to locate the
non-deterministic clauses causing the problem, and insert some cuts.

Was the ALS prolog running on an IBM compatible?  I wonder what features are
missing in ALS prolog compared to PDC prolog to make space for dynamic stack
allocation between modules (if that's what you're refering to)?

Does ALS have many of the other features I mentioned in my previous posting?

Regards,
Euan