Delivery-Date: 
Sender: info-hol-request@edu.uidaho.cs.ted
Errors-To: info-hol-request@edu.uidaho.cs.ted
Precedence: bulk
Message-Id: <m0njZNF-000CmuC@hunny.research.att.com>
Date: Thu, 15 Apr 93 15:13 EDT
From: elsa@com.att.research (Elsa Gunter)
To: shb@com.oracorp
In-Reply-To: shb@oracorp.com's message of Thu, 15 Apr 93 10:45:17 EDT <9304151445.AA13156@sparta.oracorp.com>
Subject: Simple SML/NJ question
Cc: info-hol@edu.uidaho.cs.ted

Dear Steve,
  The answer is that you can't.  I have suggested to the powers that
be that they might withhold issuing the warning when dealing with a
top-level declaration and they have said that they might get aroound
to it in some version.  Mainly, however, the view is that the warning
message in that particular instance is harmless and in all other cases
should be taken quite seriously.  There is little worse than getting a
misterious Match exception raise from the guts of somebody else's old
code.  An this can happen with val declarations if they are insinde a
functor, for example.  When I'm typing at the top-level loop I don't
worry about the warning messages.  When I'm putting the code in a file
to be repeated reloaded I usually try to do something like the
following:

	val test = [1,2];

Instead of

	val [x,y] = test;

I use something like

	val (x,y) =
	   case test of [x,y] => (x,y)
                      | _ => raise HOL_ERR{origin_structure = "top",
                                           origin_function = "_",
					   message = "This can't
happen"};

This won't give an eror message, and if you make your message more
informative than I just did, it can save you a lot of grief if you
later change the value of test but forget to change the declarartion
binding x and y.  Eliminating Match warning messages from permanent
code is good hygene and especially important when using the module
system, even if you think you know exactly how all you functors will
be applied.  Anyway, so much for my two cents worth.
				---Elsa Gunter