[lisper]

I don't want to quibble over terminology, so fine: Hoon doesn't pun integers and booleans, it conflates them. Whatever you call it, it's still a horrible hack, and IMHO if you put in your language you surrender your snark privileges when comparing your language to Lisp.

[kazinator]

Common Lisp conflates all types with Boolean. NIL, the sole instance of the NULL type in Common Lisp, is false, and an instance of every other type is true. (Of course, this situation quite good).

[lisper]

> Common Lisp conflates all types with Boolean

Yes, I know.

> (Of course, this situation quite good).

I think that's debatable. Javascript, for example, does something similar but it takes all empty containers as false, along with zero and a few other things. (Not that I am necessarily holding up Javascript as an example of good language design. My point here is just that there is not a consensus on how (or whether -- c.f. Scheme) to conflate booleans with other types.)

The salient differences between CL's boolean conflation and Hoon's are:

1. CL's conflation design is justifiable in terms of how it simplifies coding recursion over a list, which is the single most important Lisp coding idiom.

2. Hoon tries to justify using zero as true by saying that non-zero integers can carry information about the nature of a failure. (At least I've heard some people try to justify it in this way. I'm not sure if Curtis does not not.) But now you are no longer conflating integers with booleans, you are conflating integers with multiple enum types, one for every possible set of failure types. Flouting convention is one thing. Flouting convention in order to enable conflation of integers and enums undermines Hoon's claim of being strongly statically typed (at least in any interesting way).

[kazinator]

CL's conflation also means that can use NIL to indicate the absence of an object (in the usual situation in which NIL isn't a valid value). We can test for this absence glibly, using a conditional. This is at least as useful as the benefits in list recursion.

The Javascript design means that we cannot test for the absence of an integer in this manner, because a negative result could mean that a zero is present.

It could be handy from time to time. I propose a NAUGHT function for Lisp which returns true for empty sequences, empty hashes, zero (integer, real or complex) and any other nothing you can think of.

[lisper]

Sure, but if you want to make that argument then you have to deal with the fact that there is no false value which indicates the "absence of an object" in the case where the value being tested is a list. Having multiple false values really can be a feature. (They just shouldn't be integers!)