Technically, my first thought was that something was broken. Hitting C-d as soon as I got the prompt:
$ time ./wart
ready! type in an expression, then hit enter twice. ctrl-d exits.
=> nil
real 0m29.200s
user 0m27.602s
sys 0m0.000s
Anyway, I was going to test to see if you had Arc's t; but it doesn't look like it:
(if t 'hi 'bye)
020lookup.cc:28 no binding for t
=> bye
Note that it's trivial to add:
(<- t 't)
=> t
(if t 'hi 'bye)
=> hi
The reason I thought to try this was because I initially balked at maintaining false and nil at the same time with the same truth values. Then I thought of t, and suddenly the pieces clicked together: at least in part, it seems like you just want a Python-like system anyway.
Once I got the landscape laid out in my head, I started objecting to it less, because I could make sense of it. You're most of the way there:
- false is a separate, canonical false value.
- t (if you chose to have it) is a separate, canonical truth value.
- nil is an empty list, but empty lists are false.
Compare to Python's True, False, and []. The major differences being:
1. No first class boolean type. In wart, this produces more of a disconnect between t and false. t (i.e., 't) is just a normal symbol whose truth value is incidental. But false is a special, unassignable keyword.
(<- false 'hi)
=> hi
false
=> false
Python lacks symbols (you can't just say True = 'True), so this disconnect between symbolic value and keyword doesn't exist. There is still, however, a different sort of disconnect in Python because the "first class" boolean type gets contaminated by the int type:
2. You don't take Python's next logical leap. Since you already make the empty list false, other values become fair game, such as the thread's original idea (make 0 false), the empty string, other empty data structures, etc. But like I said before, I make do in such systems. Keeping nil falsy is really just your prerogative, if you want to avoid calls to empty? that much. ;)
Thanks for trying it out, and for the comments! Yeah it's gotten slow :(
I hadn't realized how close to python I've gotten. Seems right given how the whitespace and keyword args are inspired by it. On rosetta code I found a cheap way to get syntax highlighting was to tag my wart snippets with lang python :)
I've been using 1 as the default truth value, and it's not assignable either. I was trying to avoid an extra hard-coded symbol, but now that I've added false perhaps I should also add true.. I'm not averse to going whole-hog on a boolean type, I'd just like to see a concrete use case that would benefit from them. pos seems a reasonable case for keeping 0 truth-y, and the fact that lists include the empty list seems a reasonable case so far to keep nil false-y. But you're right, I might yet make empty strings and tables false-y.
(True, False = 0, 1 :( That's the ugliest thing I've ever seen python allow. At least throw a warning, python! Better no booleans than this monstrosity.)
"pos seems a reasonable case for keeping 0 truth-y"
While I personally like 0 being truthy, I don't see this as a convincing reason.
I'd treat 'pos exactly the same way as 'find. They're even conceptually similar, one finding the key and the other finding the value. For 'find, the value we find might be falsy, so truthiness isn't enough to distinguish success from failure. The same might as well be true for 'pos.
---
"But you're right, I might yet make empty strings and tables false-y."
What if the table is mutable? That's an interesting can of worms. :)
JavaScript has 7 falsy values, all of which are immutable. If we know something's always falsy, we also know it encodes a maximum of ~2.8 bits of information--and usually much less than that. It takes unusual effort to design a program that uses all 7 of those values as distinct cases of a single variable.
This means if we have a variant of Arc's (and ...) or (all ...) that short-circuits when it finds a truthy value, we don't usually have to worry about skipping over valuable information in the falsy values.
If every mutable table is falsy as long as it's empty, then a falsy value can encode some valuable information that a practical program would care about, namely the reference to a particular mutable table.
---
"(True, False = 0, 1 :( That's the ugliest thing I've ever seen python allow. At least throw a warning, python! Better no booleans than this monstrosity.)"
The PEP describes the design and rationale of introducing booleans to Python this way. Version 2.3 implements this. Version 2.2.1 preemptively implements bool(), True, and False to simplify backporting from 2.3.
Notably, the variable names "True" and "False" were chosen to be similar to the variable name "None", and all three of these are just variables, not reserved words.
Later, version 2.4 made it an error to assign to None:
I've added some messages to at least set expectations on how slow it is:
$ wart
g++ -O3 -Wall -Wextra -fno-strict-aliasing boot.cc -o wart_bin # (takes ~15 seconds)
starting up... (takes ~15 seconds)
ready! type in an expression, then hit enter twice. ctrl-d exits.
