Talk:Semipredicate problem

What is a semipredicate?
What is a semipredicate? --Abdull 08:35, 9 April 2007 (UTC)


 * In Lisp, a semipredicate is a function that can return either "false" (NIL in Common Lisp) or some useful value, where "false" means that the value is missing or there was an error . So a semipredicate function can have the "semipredicate problem" if "false" is in the domain of useful values it can return (but might not if "false" is not in that domain).


 * However, the term "semipredicate problem" seems to be a Perl-ism, judging by Google; I'd never heard of it by this name before. A more general description of the cause of this problem is "in-band error signalling". --DavidHopwood 22:30, 15 September 2007 (UTC)


 * Maybe coined by Mark-Jason Dominus? There is a chapter on it in his book Higher-Order Perl: Transforming Programs with Programs (Morgan Kaufmann, March 2005), and earlier references by him back to 2002 . I don't know whether he coined this term or just popularized it, though. --DavidHopwood 22:47, 15 September 2007 (UTC)


 * It isn't a Perlism; it's mentioned in Peter Norvig's Paradigms of Artificial Intelligence Programming. MJD's (functional programming in-) Perl book certainly helped popularize it. Gaal (talk) 14:14, 22 December 2007 (UTC)

Problem meaning and solving is incorrectly presented
The problem of the necessity of pre- or re-action to exceptional cases in a program using a library function (as mentioned in "Practical implications") is in no way avoidable by means of exception handling or any other replacement for exception case signaling.

The logic complexity remains exactly the same for the user program:
 * whether to identify exceptional arguments before the call
 * or to identify exceptional results after the call
 * or to identify exceptional signals after the call
 * or to identify exceptional signals beside the call

If you have to pre- or re-act on X different cases, then you have to so this in ANY of the methods mentioned. If you would be able to bundle the exceptional cases to some lesser number, than you could do that with ANY of the methods mentioned. If you have to extend your exceptional cases to do a more sophisticated signaling, you will have to do this with ANY of the methods mentioned.

Thus, Exceptions have exactly null point nothing to do with any solution to this problem. They are merely one of many possible ways of signaling.

Exceptions instead DO lead to a highly redundant exception handling, where the intelligence to create the exception handling code must be spend a multitude of times for each and every usage of a library function in a using module - multiplied with the multitude of persons using this library function all over the world - whether they need it or not! Java is one glancing example for a repellent against beginners: As a beginner, you must FIRST figure out what you have to do to handle some absolutely non-of-interest exceptions - which you possibly not even are able to understand - BEFORE you are able to even compile a program, not to speak about successfully running it.

PHP on the other side is a crass counter example: Its runtime functions all run without any exceptions, but as well report back every thinkable exceptional case by the help of either special result values or extra error variables in the runtime environment - allowing you to bother about exceptional cases as deep and as soon as you need or intend to do this. THIS is one of many reason, why all and every html-writing-cabable dummy in this world can write PHP too. It's exemplary coding style in my eyes.

(White-Gandalf) —Preceding unsigned comment added by 84.188.67.232 (talk) 18:26, 3 April 2009 (UTC)

Additional source
This article was recently tagged with, and has had since February 2012. If an additional source is wanted, the following might serve:

—Mark Dominus (talk) 00:16, 26 June 2013 (UTC)