At least to me, this is expected. The commit you pointed out above switched the null value to '(). The symbol `nil` still evaluates to (). But the need for evaluation implies that it isn't available in contexts that are not evaluated, such as function arguments or in this particular slot of `withs`.
Like I said, happy to revert it if you don't like it. The whole thing came up because of this conversation: https://github.com/arclanguage/anarki/pull/145#issuecomment-.... The motivation was to simplify the Arc implementation. We already have a nil representation in the underlying Racket; it seems unnecessary to so bend over backwards to switch it to something else.
Let me figure out where in the ecosystem I'm getting the nil value from. I suspect I need to switch a bunch of usages of nil in my codebase to () or '().
Then again, who knows how long it will take to fix this problem. I'll roll back for now.
Edit: I feared that rolling back may also be non-trivial, but there were only some minor conflicts. Do a `git pull`! All tests are passing, and the bugs here should be fixed now.
Sorry about all this confusion and back-and-forth spanning a year. I'm going to back off on this change now. I think none of us have the bandwidth for a change this radical.
Yeah, that seems better. I'm still tracking down two test failures, but they're not because of this. I think templates now are of type 'tem, not type 'table.
I tried to make some changes to () instead of nil, and I was not a big fan of how it looked. I found it very unusual that unless quoted, parentheses mean function application. Letting () be the way to write the empty list (and I believe it worked differently quoted from unquoted, but I'm not sure offhand) completely breaks my mental model of how Lisps are parsed.
It's failing because `(type (inst 'foo))` is different in Anarki than Arc. It's a simple change to make it work; I just want to do two things before I stop looking at it:
1. Look deeper into the template inconsistencies. Thanks for the files about this in Anarki.
2. Decide if I want to cut support for Arc, or make this code work in both. This might just involve killing the test, as it's not the _most_ useful test.
Ouch, have the tests for unit-test.arc been failing for the past year? :( :( Very sorry about that. I see the failure now.
I somehow forgot that unit-test.arc has its own tests. Could you post the instructions for running the tests in the Readme? That would also have the salubrious side effect of showing people a way to run a bunch of existing tests.
Once that last one is passing (or maybe even before it's passing), should the top-level tests.arc run these tests too? That way this can be caught not only by Travis CI, but also by people running tests.arc according to the readme.
Good question. I guess it's a question of if we have enough Anarki tests to minimze breaking changes.
If we do, then I don't know if it matters if we run unit-test.arc tests -- it's just one Arc library, presumably of several.
It's a little different than other libraries because it's what we use for Anarki unit tests.
Running it as part of Anarki's unit tests would prevent breakage, and is a simple solution to get a lot more tests added to the language. Anyone want to write a bunch of tests for Anarki itself?
Anarki isn't really intended to avoid or minimize breaking changes. The unit tests verify only that everything is internally consistent. That boundary around 'internal' should include unit-test.arc, I think.
I _think_ it's some weirdness with the nil/empty list thing. I was getting a case where (str x) resulted in the string "nil", but whatever that object was was not treated as nil, for example in conditionals.
