From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,ec21c3c7cdc7ff3e X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!news4.google.com!border1.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!peer01.cox.net!cox.net!news-out.ntli.net!newsrout1-gui.ntli.net!ntli.net!news.highwinds-media.com!newspeer1-win.ntli.net!newsfe6-gui.ntli.net.POSTED!53ab2750!not-for-mail From: "Dr. Adrian Wrigley" Subject: Re: Handling invalid objects User-Agent: Pan/0.14.2 (This is not a psychotic episode. It's a cleansing moment of clarity.) Message-Id: Newsgroups: comp.lang.ada References: <1142279908.327131.230200@j52g2000cwj.googlegroups.com> <41LSf.4126$TK2.1805@trnddc07> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Date: Sun, 19 Mar 2006 19:07:16 GMT NNTP-Posting-Host: 82.10.238.153 X-Trace: newsfe6-gui.ntli.net 1142795236 82.10.238.153 (Sun, 19 Mar 2006 19:07:16 GMT) NNTP-Posting-Date: Sun, 19 Mar 2006 19:07:16 GMT Organization: NTL Xref: g2news1.google.com comp.lang.ada:3457 Date: 2006-03-19T19:07:16+00:00 List-Id: On Sat, 18 Mar 2006 09:57:24 +0100, Jacob Sparre Andersen wrote: > Justin Gombos wrote: > >> The 'Valid attribute exists to be able to handle abnormal objects. >> >> Here's a concrete example. Suppose I have: >> >> type clock_type is mod 12; >> >> function hour_of_day return clock_type; >> >> If hour_of_day gets called and for whatever reason I cannot return >> an hour_of_day, the caller needs to know that. Exceptions are a >> poor choice. The quality and style guide advises against them for a >> good reason; exceptions are like gotos - and produce a questionable >> state. It would be more graceful for me to return an invalid value >> (like -1), so my caller can simply do a 'Valid to discover whether >> the operation was successful. > > No. The way to do that is to have proper values for all the states > you want to handle, i.e.: > > type Hours is mod 12; > > type Clock_Type (Is_Set : Boolean := False) is new > record > case Is_Set is > when True => > Time : Hours; > when False => > null; > end case; > end record; This is exactly the way I would expect this problem would be solved. It's one of the reasons for variant records. But it is still a bit messy (more verbose, extra component in names). Writing a generic just for one type is even more verbose, but in some fields you have a lot of invalid data around! In my field of stock trading, time series often have holes, probably erroneous values, and other problems and discrepencies. Tracking bad data, while keeping the code simple would be nice! It'd be great if the language allowed me to set and propagate invalid values naturally! With floating point, a NaN is the obvious choice. When you see NaNs output by your code, you know some/all of the calculation didn't work out properly. With access types, null can sometimes be used this way. But a proper invalid value would be useful. With integers, it would seem very sensible to have a NaN as well. Why did floats get a NaN value, but integers didn't? Languages often try to give facilities that can map onto hardware efficiently. But hardware tries to give exactly what the languages need, but no more. I think this vicious circle has made innovation with invalid values hard, in spite of the usefulness in software design, as well as hardware and software integrity. Of course, back in the olden days, some machines (which?) had ECC hardware, which generated an exception when invalid data was fetched from memory, and programs could deliberately write invalid bit patterns. This could be exploited to catch bugs and keep bad data from corrupting execution. Nowadays, you can't do this because the invalid bit patterns don't propagate through VM and cache subsytems (even although caches and backing stores have their own ECC). VHDL, when modelling hardware logic has a comprehensive system for tracking invalid values. Often the invalid data is irrelevant to the operation and valid data prevails. Sometimes, invalid data propagates and dominates. Raising exceptions all over the place cannot be a complete substitute. Only by building in data validity into the core of the language and/or hardware can you get widespread adoption. IEEE Floating Point shows it can be useful, inexpensive and ubiquitious. Programming guidelines, generic validity wrappers and compiler options are a poor alternative. -- Adrian