As for editing code and having it get reloaded into a running Arc automatically when you change the file, you might want to look at http://arclanguage.org/item?id=2739 .
The problem which prevents this from working nicely with nil is that hash tables in Arc do not distinguish between the value nil and a key simply not being there. The workaround is to use a default value (generally a symbol returned by (uniq)) to guarantee uniqueness for the case when the key does not exist.
Actually I know why it happens and how to fix that. The question was more like "is it a bug or a feature?" I remember that PG suggested (but forgot where I read that) to store cons' in a table when you need to distinguish nil and absence of an element but why doesn't he use that technique (or any other) himself?
I think the simple answer is that he hasn't needed that feature. 'memo and 'defmemo are used in 5 places in news.arc and it doesn't look like any of those uses would benefit from allowing nil as a value.
If someone created an application that benefited from that feature then perhaps there would be reason to redefine 'memo.
This seems to be an important part of the Arc philosophy: add a feature only when its absolutely needed.
Only now I realized that you treat memo as some kind of the way to improve performance (do you?). What I used memo for is to make sure that function won't be called twice:
When I use lazy sequences (of symbols read from input port for example) based on these definitions I can't be sure that readc somewhere inside will never be called twice if I call force for an element of this sequence twice.
So I treat this as a bug. Or maybe I'm just wrong about what memo is for at all. Am I?
For the former, I know there are guides out there, I just can't seem to find any right now. But I'll try to summarize below:
You ought to be able to install mzscheme with just
apt-get install mzscheme
although you may have to be careful about which version you get. Version 352 is the recommended, although 372 should work (at least with Anarki). Anything newer will require modifying the Arc source, and is not recommended.
You can start the server in a thread so that you can still access the REPL afterwards.
> (= app (thread (asv))) ; or (nsv), as the case may be
This should run Arc on port 8080. To serve port 80, I suggest using Apache. (http://arclanguage.com/item?id=3498 is an example of an Apache configuration for Arc.)
It's true, I can override this. But this would change the language for any consumer of my library, as well; and however bad it may be to have absent keys map to nil, it's even worse to face the possibility of breaking the language for someone else. Sure, it's an optional parameter here... but what happens if someone else has their own idea about adding an extra parameter and what it should do? Your idea is probably the right design (though 'len and 'keys and the setter for tables would have to be changed as well to fit it), but it's not the way arc currently works. Hopefully pg will pick it up and run with it, though.
I think part of the reason we were all hoping for more frequent releases was because, despite the fact that pg explicitly described arc as a 100-year language, he also stated that his design philosophy involved rapid iterations.
"I like to find (a) simple solutions (b) to overlooked problems (c) that actually need to be solved, and (d) deliver them as informally as possible, (e) starting with a very crude version 1, then (f) iterating rapidly." http://www.paulgraham.com/newthings.html
I actually think was a good plan, I just wish pg were able to follow it ;-) Even small improvements or bug fixes would make the community feel engaged.
* I don't read right parens, at least not in the multiline case. Instead, I read the indentation and the contents of the line, so the parens really don't get in the way at all.
I do think the : operator is an interesting idea for the single line case, when you might have something like
(foo a (bar b (baz c))) => (foo a : bar b : baz c)
This has the disadvantage that someone needs to merge the mob and main branches regularly, which may make it a little less like a true wiki. But I still think http://repo.or.cz/ is a good option.
> However, none of the rest of us can figure out how to make our own github-based repositories fully open (i.e. publicly writeable).
The easiest way to host a open source repository is probably http://repo.or.cz/, which allows setting up a "mob" user to allow wiki-style pushing like we currently have under Anarki. Obviously the same is possible in github, but I don't know how to set it up.
