Sender: info-hol-request@leopard.cs.byu.edu
Errors-To: info-hol-request@leopard.cs.byu.edu
Precedence: list
To: reetz <reetz@ira.uka.de>
Cc: info-hol@leopard.cs.byu.edu
Subject: Re: better error messages in hol90?
In-Reply-To: Your message of "Tue, 21 Nov 1995 09:35:13 +0100." <"iraun1.ira.878:21.11.95.08.35.46"@ira.uka.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 21 Nov 1995 10:55:32 +0100
From: Donald Syme <Donald.Syme@cl.cam.ac.uk>
Message-Id: <"swan.cl.cam.:084890:951121105610"@cl.cam.ac.uk>


Ralf writes:

> Having print out the whole exception hierarchy would be very
> comfortable for debugging. I think it would ease finding bugs.
> But I wonder about memory consumption. How much memory do we
> need for that? Consider a deep calling sequence (which may
> happen often as e.g. with (DEPTH_CONV my_buggy_one_I_want_to_test_CONV)).
> I just don't know. As memory consumption is critical for hol90, 
> we should be careful with that and first try out these several
> alternatives.

The memory occupied by the exception cells would, I think, be
small.  For example, none of the strings in
	raise HOL_EXN{origin_structure="<very large string>",
                     origin_function="<very large string>"
                     message="etc."};

would get copied - only one cell should get created here, probably
containing 3-4 pointers (to the strings, which are generated at compile
time), which should make for around 20 bytes.
Even if it was 50 that would still mean 20,000 wrapped
exceptions before a megabyte was used up.

Using concatenation would use up alot more memory, since a new string
will get allocated as the result of each concatenation.

Lastly, if memory consumption really does prove a problem, then
we could add an option to make the WRAP_ERR function not
wrap errors at all.  I really don't think it should be a problem 
though.

BTW, I shoud note that TkHol helps with viewing 
HOL_ERR's - e.g. any call to ML made via the interface tools
automatically has 
	handle e => Raise e
wrapped around it, and the error will appear as a dialog box.  No
stack trace is displayed, of course, but it saves some typing.


> I would strongly recommend not to depend on a however ``hacked''
> version of nj/sml for printing exceptions. The already existing
> dependency of hol90 on nj/sml only is painful enough.
> Considering non-compatible changes, you almost always don't get
> something for nothing. I personally feel that getting much
> better error messages is worth changing the code. But that's how
> I see it. Maybe other people around here do not agree?

hol90 would *not* be dependent on the hack, though a hol90
built on top of a hacked SMLNJ might be easier to use than
a hol90 built on top of a vanilla one.  The functional behaviour
and specification of the system would not change at all - this
is purely an interface issue.  The problem is simply that SMLNJ does not 
print user defined top level exceptions, whereas other ML
systems like Harlequin ML (due out in Feb 96??) do.  If we can fix
SMLNJ enough to make hol90 sufficiently usable then I think it is worth
offering as an option.

Speaking of Harlequin ML, I saw a demo of 
it a few weeks ago, and was quite impressed.
It's costs $$$, but it looks good.  I think the guys giving the demo
were quite surprised when the first thing I asked them was
not about their fancy compiler, but simply whether user defined
exceptions get printed at the top level!!

I should add that Richard Boulton and I are taking portability 
seriously in the hol90 work we are currently doing.  For instance,
Richard has been looking at a port to PolyML.  


Cheers,
Don Syme