a) Where you say "mappend [do _]", you can just say "apply + nil". Actually, I've been using "apply join", but it turns out that performs much worse:

  arc> (time10:mappend idfn (n-of 10000 nil))
  time: 468 msec.
  nil
  arc> (time10:apply join (n-of 10000 nil))
  time: 50454 msec.
  nil
  arc> (time10:apply + nil (n-of 10000 nil))
  time: 437 msec.
  nil

c) Not that it'll really save anything when it comes to the overall computational complexity, but this version of list length comparison will only traverse the lists up to the end of the shorter one:

  (def longer-list (a b)
    (if a
      (if b
        (longer-list cdr.a cdr.b)
        t)
      nil))

e) There's no need to call 'testify.

After incorporating a bunch of this feedback--I didn't pit '< against '> --the code might look like this:

  (def sort-by-commonest5r1 (seq)
    (apply + nil
      (sort longer-list
        ( (afn (xs cxs ys)
            (if xs
              (withs (x car.xs
                      f [isnt _ x]
                      r (reclist [if (f:car _) _] xs)
                      cr len.r)
                (self r cr (cons (firstn (- cxs cr) xs) ys)))
              ys))
          (sort > seq) len.seq nil))))

  (def sort-by-commonest5r2 (seq)
    (apply join
      (sort longer-list
        ( (afn (rest bins)
            (iflet (sample . rest) rest
              ( (rfn self2 (bin rest)
                  (if rest
                    (let first car.rest
                      (if (is sample first)
                        (self2 (cons first bin) cdr.rest)
                        (self rest (cons bin bins))))
                    (cons bin bins)))
                list.sample rest)
              bins))
          (sort > seq) nil))))

  arc> (time:repeat 100 sort-by-commonest5r1.data)
  time: 18390 msec.
  nil
  arc> (time:repeat 100 sort-by-commonest5r2.data)
  time: 20437 msec.
  nil
  arc> (time:repeat 100 sort-by-commonest5.data)
  time: 19594 msec.
  nil

I use XD to express careless fanaticism. The three pillars of XD are as follows:

- Euphoria: http://www.pixiv.net/member_illust.php?mode=medium&illus...

- Direction in life: http://www.pixiv.net/member_illust.php?mode=medium&illus...

And my favorite,

At this point, the basic evaluation model is really buggy, mostly thanks to tons of trivial typos. Nevertheless, there's already a REPL where it's possible to accomplish a few basic calculations: http://rocketnia.github.com/rainbow-js/test/

Be careful if you're on a very stringent data regimen, as the REPL page loads the unminified rainbow.js, which is over half a megabyte in size. :-p I'd minify it, but the last time I tried, the minified version was even more broken. (I'm not doing anything special with property name manipulation--I'm actually writing this with the Closure Compiler in mind, just in case--so I think I must have broken the minifier.)

The REPL can't accomplish anything as ambitious as arc.arc... and at this point it can't even accomplish anything as ambitious as 'def! If you're having trouble at the REPL and want to see some expressions that actually work, take a look at rainbow.test.js--which currently has no real tests, just pastes from the REPL.

There's a catch: My reader code is in continuation-passing style, and if the input's too long, it goes into a stack overflow.

Fortunately, the reason it's in CPS is so that it can process the input asynchronously. As long as it's actually working asynchronously, its continuation callbacks occur on fresh event stacks rather than piling up. I could go into more details, but what's important is that for now, submitting the input in smaller pieces is an effective, if ugly, workaround:

  var arcArc = document.getElementsByTagName( "textarea" )[ 0 ].
      value.split( "\n" );
  function readRest() {
      if ( arcArc.length === 0 ) return;
      consoleIn.o.writeString( arcArc.shift() + "\n" );
      setTimeout( readRest, 0 );
  }
  readRest();

"Actually, if you you paste from Java Rainbow's arc.arc source yourself, you'll probably find that Rainbow.js encounters a stack overflow error. At this point it's necessary to enter it in more bite-size pieces. Right now you can accomplish this by pasting all of arc.arc into the input box, then entering the following code into a JavaScript console (not the Arc console!) to have it entered one line at a time:

[the JS code I pasted above]"

In Chrome, the JavaScript console is available under "(wrench icon) > Tools > JavaScript console." On Firefox, I tested it using Firebug's console tab, but I think the Error Console might work too.

Also, pasting the JavaScript snippet all at once should be fine. The point is to enter the Arc code in bite-size pieces, and the JavaScript snippet just automates that process.

Done! Now the reader only uses a number of JavaScript stack frames proportional to the amount of nesting of the program, rather than the number of characters. Feel free to just paste all of arc.arc into the REPL and hit enter. ^_^

I've also tested the REPL on more browsers. The only one that really had a problem was IE 8, and that was because of the code of the REPL interface itself rather than the Rainbow.js runtime. It should work in IE 8 now... except that the performance is terrible there. XD

Anarki[1] already lets us change the square bracket behavior by redefining the 'make-br-fn macro. In ar[2], it's the 'square-bracket macro.

Here's my take on your idea. When the operator is actually a macro, I just treat it the old way rather than unsuccessfully calling 'apply on it:

  (mac make-br-fn contents
    (iflet (op . args) contents
      (if (isa (bound&eval op) 'mac)
        `(fn (_) ,contents)
        (w/uniq g-args
          `(fn ,g-args
             (apply ,@(map (fn (x) (case x _ `(pop ,g-args) x))
                           contents)
                    ,g-args))))
      `(fn args (whenlet (op . args) args (apply op args)))))

  arc> ((make-br-fn car) '(1 2 3))
  1
  arc> ((make-br-fn list 1 _ _ 4 _) 2 3 5 6)
  (1 2 3 4 5 6)
  arc> (macex '(make-br-fn list 1 _ _ 4 _))
  (fn gs1022 (apply list 1 (pop gs1022) (pop gs1022) 4 (pop gs1022) gs1022))
  arc> (macex '(make-br-fn list))
  (fn gs1023 (apply list gs1023))
  arc> (macex '(make-br-fn))
  (fn args (whenlet (op . args) args (apply op args)))
  arc> ((make-br-fn))
  nil
  arc> ((make-br-fn) + 1 2)
  3
  arc> (((make-br-fn fn (it) _.it) inc) 4)
  Error: "reference to undefined identifier: _fn"
  arc> (((make-br-fn afn (it) _.it) inc) 4)
  5

---

[1] https://github.com/nex3/arc

Furthermore, you're reading from stdin, the same stream the commands are read from, so what you're reading actually starts right after the ')' character and includes the same newline you used to enter the command. I think someone here might have made a fix for this too (probably Pauan or aw), but you might be able to work around it like this:

  arc> (do (readline) (...now your *actual* stdin-reading code...))

...separate paragraphs like this...

...and indent code like this:

  You can insert links like *this*... http://arclanguage.org/formatdoc
  
  ...separate paragraphs like *this*...
  
  ...and indent code like *this*:
  
    You can insert links like *this*... http://arclanguage.org/formatdoc
    
    ...separate paragraphs like *this*...
    
    ...and indent code like *this*:

I mean, yeah, you could have a table where the keys are strings, and treat that as the metadata, but uuugh it's clunky and I've found myself disliking the whole "global table to hold data" thing more and more, recently.

I don't like len!sym being 1 either. I think ppr.arc is the thing that should be fixed, perhaps by having it use its own spinoff of 'len. But I didn't try to fix that; I just did the minimal change needed to get len.nil to work properly again.

"Conditionally include things in a string"

Sorry if I enter into a bit of drama here.... I don't have anything against you or aw, but every time I see that comment, something nags at me. :)

At the time, there were about six reasons I didn't respond to that comment (which was a reply to a comment of mine):

1) I didn't consider it to be a "brilliant use," since the workaround without it would be negligible:

  (string "You are going "
          (if (> speed 100) "very " "")
          "fast")

  arc> (= speed 2)
  2
  arc> (prn "You are going " (if (> speed 100) "very ") "fast")
  You are going nilfast
  "You are going "

4) It had upvotes too--at least one upvote at the time I first read it. Apparently, what I thought was common sense would be outnumbered.

5) I hadn't programmed in Arc that much yet. Maybe the upvoter(s) saw something there I didn't. At any rate, I'd probably be able to discuss the pros and cons better once I'd used Arc for a while.

6) I did say "I can't think of a single time," and this was a single example. I kinda decided to eat my words on account of that. :-p