The 'soft, spongy' type system is nice to see. That kind of strong dynamism is a good choice for the application: it will do the wrong thing sometimes, but will throw fewer show-stopping errors, which are really disheartening for casuals.<p>I do regard casting not-numbers to 0 as a flaw. I've had plenty of bugs where I wished `nil` would automatically cast to to `""` in string position, or the empty list/dict: but I have never, once, wanted a missing number to cast to 0.<p>The number zero doesn't have the "semantics of emptiness" in programming. It shouldn't be treated as false, either, unless we're dealing with a "raw" language, in which case, one should have to at least <i>cast</i> to boolean to get the truthiness of anything.<p>Personally, I would promote this to an error, because the other option, 'NaN', is itself a source of confusion. But at least NaN-poisoning the calculation will eventually inform the user that "htree" isn't a number.