Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site mit-eddie.UUCP Path: utzoo!linus!security!genrad!mit-eddie!barmar From: barmar@mit-eddie.UUCP (Barry Margolin) Newsgroups: net.lang Subject: Re: Strong Typing and Ignorance Message-ID: <1016@mit-eddie.UUCP> Date: Thu, 8-Dec-83 05:13:48 EST Article-I.D.: mit-eddi.1016 Posted: Thu Dec 8 05:13:48 1983 Date-Received: Fri, 9-Dec-83 06:31:33 EST References: <2892@utcsrgv.UUCP> <137@csd1.UUCP> <1457@rlgvax.UUCP> Organization: MIT, Cambridge, MA Lines: 44 ... the assignment of an integer to a subrange-typed variable requires runtime checking. Has any work been done on proving such assignments correct given constraints on the values assumed by the integers in question? I don't know about research, but isn't that what the whole idea of types is supposed to obviate? Also, unless some runtime check has been done the constraints cannot be assumed to be true, since the values of most variables are determined by something external to the program, namely user input. This is also the only time you should ever run into an assignment from a superset to a subset, i.e. the assignment of the input variable to an internal variable of a subtype. If the program explicitly checks that the user's input is valid then an ideal optimizing compiler would recognize that a check was not needed in the assignment code (hmm, did I just repeat what the original submission was saying?) On the other hand, another way to do this would be to have a handler for the condition signaled if the range-checking failed. The latter doesn't require as much smarts from the compiler, and also has a chance of producing better code in some types of type conversion. For instance, a good way in PL/I to turn a user input into a numeric value is: on conversion begin; /* Do something about bad input */ ... end; fixed_bin_var = fixed (char_var); revert conversion; This could produce better code than something like if valid_fixed_bin (char_var) then fixed_bin_var = fixed (char_var); else /* Do something about bad input */ ... because you only have to examine the char_var variable once. -- Barry Margolin ARPA: barmar@MIT-Multics UUCP: ..!genrad!mit-eddie!barmar