3 ms·

Right, thanks for the insight. A further thought: `apple_pie` wouldn't actually be problematic, in the sense that we could deduce `¬even(apple_pie)` from the w

Right, thanks for the insight. A further thought: `apple_pie` wouldn't actually be problematic, in the sense that we could deduce `¬even(apple_pie)` from the way it's currently written. This is because `apple_pie` is obviously neither `0` nor `s(s(N))`. Of course, this might not be desirable philosophically since it might be preferable to consider applying `even` to `apple_pie` nonsense since they are of different types (informally speaking). Is this right? Am I missing something?

tom_mellior 8y ago
> A further thought: `apple_pie` wouldn't actually be problematic, in the sense that we could deduce `¬even(apple_pie)` from the way it's currently written. Yes. We can have the same behavior with the following Prolog implementation: not_even(X) :- X \= 0, ( X \= s(s(_N)) ; X = s(s(N)), not_even(N) ). (This is a translation of the article's definition, except that I added the "X = s(s(N))" condition to make the case distinction explicit and actually bind N in the second branch. It wouldn't work without this for the reason I mentioned above, of deducing this equality from a failure.) ?- not_even(s(s(0))). false. ?- not_even(s(s(s(0)))). true . ?- not_even(apple_pie). true . > Of course, this might not be desirable philosophically since it might be preferable to consider applying `even` to `apple_pie` nonsense since they are of different types (informally speaking). Right. This is one of the reasons why some Prolog extensions and Prolog-like languages like Mercury add static type systems. It makes little sense to ask whether apple pie is even or odd.