"I think we should make anarki the default; 3.1 has some bugs and gotchas. Even if the docs will only support arc 3.1 for starters, there's still value in combining them with anarki, I think."
Seems like you and I disagree about this at the moment. :)
---
"I love the favicon :)"
Eh? Isn't that the favicon that comes bundled with Arc? (Hmm, I see the "ref" pages have no favicon at all. O.o )
As opposed to the Arc 3.1 favicon, I prefer the version currently used here on arclanguage.org. Its colors seem to have been tweaked to address the blue-and-black contrast issue identified on the original logo thread: http://arclanguage.org/item?id=9438
"There's no value in being strictly compatible with an old, buggy release that never guaranteed compatibility in the first place. We should instead focus on a live version that's getting fixes over time, whether it's anarki or arc-nu or rainbow-js or something else."
If we agree it's a fix, then we can document it the correct way and just take note of which bugs exist in which implementations. Arc 3.1 is just one implementation for these purposes.
If someone wants a real reference implementation to test against, they can use a version of Arc that has relatively few bugs, such as Anarki's stable branch or your curated Arc repo.
Like you, I believe the Arc language should be free to change in ways that break existing code. However, I think some of the Arc community's most large-scale projects have been the multiple implementations of Arc, and I think that's worth representing on the website, even if the community evolves to have some other focus later on.
---
Speaking of choosing a canonical, main-documentation-worthy variant of Arc, I've always been reluctant to develop upon any existing implementation of Arc, due to licensing.
Now that I take yet another look at the Artistic License 2.0, I think it isn't nearly as complicated as I've interpreted it in the past. It's still odd, though: I think technically anyone can make closed-source products out of Arc, Anarki, Arc/Nu, Rainbow, Rainbow.js, Jarc, etc. as long as they give their source code to Paul Graham and Robert Morris in private (per section (4)(a)).
I'd prefer to use a more generic permissive license, something that obviously permits distribution of closed-source binaries, rather than being quasi-permissive depending on the participation of pg and rtm.
"Like you, I believe the Arc language should be free to change in ways that break existing code. However, I think some of the Arc community's most large-scale projects have been the multiple implementations of Arc, and I think that's worth representing on the website, even if the community evolves to have some other focus later on."
I'm not sure how to interpret this :) Were you suggesting that we should highlight things like arc-nu and arcueid? I'm totally supportive of that. It didn't occur to me to want incompatible variants to steal all the thunder from compatible variants -- especially since I would like to be utterly oblivious to compatibility :) Or did you mean something else?
(At the risk of unnecessarily repeating myself,) I am only opposed to linking flatly to http://ycombinator.com/arc/arc3.1.tar (die! die! :) without any provisos or qualifications. We already have a frontpage for arc3.1.tar; we don't need another.
"Were you suggesting that we should highlight things like arc-nu and arcueid?"
Well, I'm suggesting that they share documentation for their common features. If that sharing gives them more or less prominence on the site, I don't mind either way.
I think author intent matters here. If a new so-called "Arc implementation" comes along, sometimes it'll sacrifice improvements for the sake of compatibility (arcueid), and sometimes it'll sacrifice compatibility for the sake of improvements (Semi-Arc). I think this will correlate with our ability to share documentation between projects.
Jarc is an interesting case. It shows how subjective I am: Jarc changes the treatment of unbound variables to make it easier to call Java methods, but this doesn't affect most working Arc programs. Jarc doesn't support continuations, but it would if it could. I consider Jarc to be on the side of compatibility, but maybe only because I've found it easy to write Arc programs that work on Jarc despite these differences. Maybe I would have judged Semi-Arc the same way, if only my programs didn't rely on quite so much hygiene violation and ssyntax manipulation.
---
"I would like to be utterly oblivious to compatibility :) "
Yeah. Even though I recommend sharing documentation, I don't look forward to splitting hairs in what amounts to a standardization process.
I see it as work too. Maybe we should reject this rational thinking and focus on something we like.
Personally, I like the idea of jumping ship to Arc/Nu (or merging!). Then we can port the Arc/Nu compiler to Arc/Nu and extend it to compile itself to every platform; who needs other implementations? :-p As I understand it, Arc/Nu has a fully reorganized codebase and very few entrenched users, so it's reasonable to refactor it again and again.
Arc/Nu has a "3.1" folder and a "nu" folder, so the website could introduce the Arc 3.1 documentation as though it's really just documentation for a compatibility mode. ;) Meanwhile, anyone who has a passion for consistency can work on documenting this mode in the same way I described above. :-p
Come to think of it, I might just be outlining more and more work. If Arc/Nu somehow becomes a vibrant community project, it's design by committee, right? I'm going to get some sleep.
"Interesting, I hadn't paid attention to the licensing terms. I thought anybody could do anything with the code, period."
Whoops, you just reminded me it isn't that bad. :) Per (4)(b), a closed-source project (or a project under a different license) is just fine as long as it doesn't interfere with a separate Arc installation and it doesn't call itself "Arc."
Playing out some scenarios...
Theoretically, I could invoke (4)(b) to continue development of Rainbow.js under the MIT license plus a few restrictions. In particular, any forks of Rainbow.js could not be named "Arc" or interfere with Arc, but they could be named (and/or interfere with) "Rainbow" or "Rainbow.js."
Interestingly, the Artistic License 2.0 grants an explicit patent license for the Copyright Holder's patents, but not for the Contributors' patents. Not that this is necessarily a problem; I like the MIT license, but it doesn't specifically mention patents at all.
It seems like I'm now okay with AL2.0. Effectively the only thing it prohibits is using the name "Arc" without respecting the original creators. That condition would pretty much be ensured by trademark law anyway, if Arc were a product being sold.
P.S.: I'm not a lawyer. As if that weren't enough, I've demonstrated an ability to misunderstand this license over and over and over. :)
