On 2017-12-11 5:21 PM, Sean McAfee wrote:
Well, /any/ function or operator that returns a boolean /could/ return a Failure
instead of (or in addition to) False to provide additional information to those
who want it, but if the condition is not really a Failure, wouldn't that be
misleading?  Like this highly contrived example:

For my part, in the design of my Muldis D programming language (whose design is influenced a lot by Perl 6), I use the data type name "Excuse" as my analogous core concept to Failure or the Exception of some languages. The idea is we have some context where a normal value doesn't exist, so the Excuse value gives the excuse for not having one. The singleton Excuse value named No_Reason is the canonical analogy to a generic unqualified null/nil/undef singleton typical in other languages. The Excuse value named Div_By_Zero is what would result from a number of mathematical operators, and there are others for common situations, and users can define more. The idea here is that an Excuse can either be a stored value such as how null is used in a SQL database, or it can be a result from an operation that doesn't give a normal result. An Excuse does compare equal to itself. -- Darren Duncan

Reply via email to