But your code only make first cell of x to be destructive.

  (let insorted (insert-sorted < 2 x)
         (scar x (car insorted))
         (scdr x (cdr insorted)))

I think insort should modify the list, not merely assign a new list.

Some demo code:

  (def insort1 (test elt seq)
    (if (no seq)
         (list elt)
        (test elt (car seq))
         (with (first (car seq) rest (cdr seq))
          (scar seq elt)
          (scdr seq (cons first rest)))
        (no (cdr seq))
          (scdr seq (list elt))
        (insort1 test elt (cdr seq))))
  
  (mac insort (test elt seq)
    `(do (insort1 ,test ,elt ,seq) ,seq))

  arc> (= y (= x '(1 3 5)))
  (1 3 5)
  arc> (insort < 2 x)
  (1 2 3 5)
  arc> x
  (1 2 3 5)
  arc> y
  (1 2 3 5)
  arc> (insort < 0 x)
  (0 1 2 3 5)
  arc> x
  (0 1 2 3 5)
  arc> y
  (0 1 2 3 5)
  arc> (insort < 6 x)
  (0 1 2 3 5 6)
  arc> x
  (0 1 2 3 5 6)
  arc> y
  (0 1 2 3 5 6)
  arc> (= y (= x nil))
  nil
  arc> (insort < 1 x)
  nil
  arc> x
  nil
  arc> y
  nil

  (def destructive-cons (elt seq)
    ; Note: (push elt seq) won't work, because push is a macro on the "place",
    ; and seq isn't the proper "place" to mutate (push will just mutate the local
    ; binding of seq).  This function will actually mutate the cons cell being
    ; pointed at by seq.
    (let (first . rest) seq
      (scar seq elt)
      (scdr seq (cons first rest)))
    seq)

  (def insorter (test elt seq)
    (if (no seq)
         (list elt)
        (test elt (car seq))
         (destructive-cons elt seq)
        (do1 seq
             ((afn (prev cell)
                (if (or (no cell) (test elt (car cell)))
                    (scdr prev (cons elt cell))
                    (self cell (cdr cell))))
              seq (cdr seq)))))

  (mac insorted (test elt seq)
    `(zap [insorter ,test ,elt _] ,seq))

  arc> (= y (= x '(1 3 5)))
  (1 3 5)
  arc> (insorted < 2 x)
  (1 2 3 5)
  arc> x
  (1 2 3 5)
  arc> y
  (1 2 3 5)
  arc> (insorted < 0 x)
  (0 1 2 3 5)
  arc> x
  (0 1 2 3 5)
  arc> y
  (0 1 2 3 5)
  arc> (insorted < 6 x)
  (0 1 2 3 5 6)
  arc> x
  (0 1 2 3 5 6)
  arc> y
  (0 1 2 3 5 6)
  arc> (= y (= x nil))
  nil
  arc> (insorted < 1 x)
  (1)
  arc> x
  (1)
  arc> y
  nil

  arc> (= x nil)
  nil
  arc> (scar x 1)
  Error: "set-car!: expected argument of type <pair>; given nil"
  arc> (scdr x '(2))
  Error: "set-cdr!: expected argument of type <pair>; given nil"

  arc> (= y (= x '(a b c)))
  (a b c)
  arc> (= z (= w '(1 2 3)))
  (1 2 3)
  arc> (swap x w)
  (a b c)
  arc> x
  (1 2 3)
  arc> y
  (a b c)
  arc> z
  (1 2 3)
  arc> w
  (a b c)

About the nil problem, maybe we should nil terminate list this way: (1 2 nil), instead of (1 2 . nil). just a joke. :)

Yeah, I agree with this. I weakly think (without evidence) that arc's destructive ops are more functional, and it encourages a better style to not constantly make assumptions about precisely which cons cells go where.

On the other hand, a set of 'alias-friendly' functions could coexist with the existing primitives.

I'm not a designer, so currently I just use bootstrap. I wish there are some experts here, so that our site can have a shiny and unique look and feel.

I made a couple of tweaks to the menus. 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.

I love the favicon :)

I pointed at external resources where they're still useful. No reason to copy the default tutorial, for example, and everyone should know about http://tryarc.org.

Does anybody use anarki's arc.sh script? I just tried it from a different directory and it failed on me. If others can confirm the problem I'll try to fix it.

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 )

I was thinking of asking you to react to http://arclanguage.org/item?id=17782, but that post works. :-p

---

"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)).

---

"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."

Sounds like you and dram are saying the same thing: http://arclanguage.org/item?id=17816. I think I now understand what y'all are suggesting :)

---

"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?

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 :) "

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

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.

If anarki is stickly compatibe with arc3.1, or at least have a branch which make compatibility as one of its goal, then its good to make anarki as default.

Currently there are some compatibility issues, so I'm afraid it will confuse starters.

tryarc.org is really cool, I was not aware of it.

arc.sh also fails here.

The gotchas I'm concerned with are enumerated at https://sites.google.com/site/arclanguagewiki/arc-3_1/known-.... I think they're far worse than any incompatibilities anarki causes. Anarki's incompatibilities at least error out immediately, but some of these gotchas are quite insidious. They are they reason we try to push newcomers away from installing arc3.1 at https://sites.google.com/site/arclanguagewiki/getting-starte....

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.

The documentation at arcfn has been out of sync with arc3.1 as well as anarki for many years. I love that we're fixing this, but I'd rather gradually bring the docs in sync over time than switch to a more misleading version of the code.

Some random thoughts:

1. want to learn about Lisp and Arc

2. want to learn about language design and implementation

3. want to deploy a clone of Hacker News

4. want to use Arc as a daily programming tool

5. want to make a fork :)

For 1, I think bugs in Arc is not too fatal for those guys, we just need to make them aware of those bugs.

For 2, they need to, and I think they would like to investigate those bugs, so I think its better to let them fix those bugs by themself, learning from mistakes is effective. :)

For 3, those people will not tolerant of bugs, but compatibility is also critical for them, both about codes and data. As they need to consider how much work they will need to do when PG release a new version.

For 4, they will satisfied with anarki or other forks.

For 5, as a fork, they need to treat something as a reference, and I think vanilla arc is the most suitable one.

So I think it's more suitable to make vanilla arc as default, as it can make more people happy. Anyone not satisfied with it can choose forks.

PS: I'm in group 3. :)

I'm not sure how far has anarki diverged from vanilla arc, and whether data is still compatibe with it, so I decide to use vanilla arc, and integrate some bug fixes.

But I still think you're chasing some mythic notion of compatibility. From http://www.arclanguage.org: "Arc is still fluid and future releases are guaranteed to break all your code." There is no "reference" here; if you want upgrades to be smooth you're guaranteed to be disappointed.

"if PG can release a new version, that would be the most suitable choice. :)"

Even if that new version gets no bugfixes for 4 years?! O_O What if that next version takes ten years to show up? Heck, what if it takes a year to show up. Are you sure you'll still care?

I don't know anybody on this site who still uses arc 3.1. Even my 'curated bugfixes' repo at http://github.com/akkartik/arc was a short-lived thing. It's just the nature of this community to go off on some tangent :)

Have you read the gotchas page? Many of those gotchas I'm talking about aren't minor bugs. They took weeks of pain and in some cases months to come up with a fix. I wouldn't wish that pain on anyone. For example, for several months I thought that arc and racket was just really slow, all it could do was 1 request per second. But it just seemed slow because all my requests were getting throttled because of some code in HN that most sites will never need, because they'll never have that much traffic.

Perhaps the compromise position would be the 'stable' branch of anarki. But I'm not aware of anyone who uses it. I really think that if you want to benefit from this community anarki is the most common baseline, and the whole point of a new site is to give newcomers the benefit of more updated information than the existing site, and to get them using what the veterans here are most familiar with so that they can get their questions answered soonest.

If the community has new ideas should we go try them out, or should we wait for PG to first grant them his permission? I know what he'd do :) And if people here have new ideas it's worth getting them feedback from others as long as we can be responsive to issues when they come up. And I think we're pretty responsive :) Arc is a bleeding-edge language, and we shouldn't try to act otherwise.

(Incidentally, yes, the HN site on anarki is indeed data-incompatible with arc3.1. It hashes passwords with sha512 rather than sha1, for one: http://arclanguage.org/item?id=17278. Which would you use?)

I'm not against to bug fixes, but I think anarki has go far beyond that.

In general, I'm uncomfortable supporting a version that we are not empowered to update. That's basically my biggest objection.

This community has had a culture of letting newcomers come in and show off new ideas to each other. I think that is valuable, so I'm in favor of allowing anyone to update the default version most of us use. But we can agree to disagree on that score :)

And we can treat anarki as a fully fork, with no restriction and full freedom.

I'll quote PG and RTM again: "Arc is still fluid and future releases are guaranteed to break all your code." http://www.arclanguage.org

I interpret this sentence on the frontpage to mean that he will not be concerned about compatibility. Arc is for exploratory programming. If you have users you're on your own. I really don't see how you can interpret it any other way.

First I transformed all existing hashes:

  (maptable [list 'sha512_sha1 (sha512 _)] hpasswords*)

  (= hpasswords*.user
     (list 'sha512 (sha512 password)))

But then how would they ever migrate beyond sha1? Would the hundred-year language save passwords in a way that gets more insecure every year?

  (sha512 (+ (sha1 pw) user-salt site-salt))

There may be some compatibility issues.

If anarki is mostly compatible with the vanilla one, I think we can just put docs under http://arclanguage.github.io/doc, and add notes if some functions differently between them.

This is about stuff that overlapped by this two. For extensions and new libraries in anarki, we can make a dedicated page for them. e.g. http://arclanguage.github.io/anarki.

---

A project like this should probably use an "arclanguage.github.io" repo rather than some other repo's gh-pages branch.[1]

The arcfn static site generator may lead to some hassle. The generated website artifacts need to be pushed to the master branch, so they'll be the first thing someone sees when they delve into the repo to make a wiki edit. GitHub goes out of its way to make it easy to edit a repo as though it's a wiki[2], but that method of update won't trigger a very expressive build language[3], let alone anything that supports an Arc-based generator. Unless we have another server that does builds in response to a GitHub post-receive hook[4], in which case why not host the website there instead?

To use a custom generator, or to use Jekyll directly... both of these choices seem to have problems.

Another option would be to do keep Arc code inside <script> tags and run it with something like Rainbow.js, but search engines probably wouldn't index any content generated this way.

Hopefully someone here will be more optimistic about these ideas than I am. ^_^

[1] https://help.github.com/articles/creating-pages-with-the-aut...

[2] https://github.com/blog/844-forking-with-the-edit-button

[3] http://jekyllbootstrap.com/lessons/jekyll-introduction.html#...

Some quick thoughts:

Can we split arcfn docs into two parts: tutorial and reference.

The tutorial part can integrate with current Google Site wiki contents, and can be renderred by Jekyll so it can be more like a wiki.

And the reference part need to be generate locally and then push the static html to the repo.

All those two part can reside on "arclanguage.github.io" repo.

The repo structure may be like this:

  arclanguage.github.io/
  |-- index.html
  |-- tutorial/ ; or move all stuffs to the top dir?
  |-- docs/     ; static html. (reference instead of docs?)
  |-- _docs/    ; source of docs
  |-- anarki/
  |-- jarc/
  |-- ...

Please create a new repo named arclanguage.github.io, then I'll do some initial work.

http://comments.gmane.org/gmane.lisp.scheme.plt/14787

In ac.scm, in the arc compiler ac, arc strings are translated using ac-string. I've tried instrumenting the output of ac-string, and it seems mutable when it's encountered. And yet it's immutable by the time I return to the prompt:

  arc> ($.immutable? "abc")
  #f  # printed inside *ac-string*
  #t  # return value

---

I tried bisecting the git history, and the stable branch, which still requires mzscheme, has mutable strings. But sometime in 2011 when the master branch switched to using racket and stopped working with mzscheme, strings went immutable again. Still investigating..

---

Back in Feb 2011, waterhouse provided a bugfix for arc's mutable pairs. http://arclanguage.org/item?id=13616. https://github.com/arclanguage/anarki/commit/cea8a4c5e9. This change requires a racket-only lib, and so arc stopped working with the old mzscheme versions. Prior to it, modifying strings worked in mzscheme but not in racket. So it seems to be something about the move from mzscheme 372 to racket.

---

Update 34 minutes later: It seems eval in racket emits immutable strings even when given mutable strings. Since everything passes through racket's eval it doesn't matter how much arc twists and turns to avoid immutability.

  $ racket
  > (immutable? "abc")
  #t
  > (immutable? (string-copy "abc"))
  #f
  > (immutable? (eval (string-copy "abc")))
  #t

Here is a quick and dirty patch for arc3.1, it postpones string-copy and let it run by eval.

Not sure if it will cause some other problem.

  50,51c50,51
  <           (unescape-ats s))
  <       (string-copy s)))          ; avoid immutable strings
  ---
  >           `(string-copy ,(unescape-ats s)))
  >       `(string-copy ,s)))          ; avoid immutable strings

https://github.com/Pauan/ar/commit/a2c1939936846b665eccf06d0...

BTW, I think `(unescape-ats s)` also needs to be treated as the same.

I'd like to run some tests to make sure it does not cause much problem.

I found this one:

https://github.com/conanite/rainbow/tree/master/src/arc/lib/...

But it failed with following error when using arc3.1.

  arc> (load "unit-test.arc")
  nil
  arc> (rat)
  Error: "_dfn: undefined;\n cannot reference undefined identifier"

I've added a few piecemeal tests over the years (all the .t files in the repo), and there's also some tests in my curated repo (http://github.com/akkartik/arc). All those seem ok..

---

Looks like dfn is a rainbow innovation: http://arclanguage.org/item?id=10539

---

I've also added/plagiarized rainbow's tests to the repo: https://github.com/arclanguage/anarki/commit/68be3c0f4d. Joys of the perl artistic license.

There's still a couple of syntax tests that are failing, likely because of test harness issues. And I'd like to unify all the different tests into a single framework. For future work..

---