The latest checkin supports complex numbers and a little bit of trigonometry, and it also goes faster, yippee! I was planning to use arc to play with fractals (ergo need for complex numbers) when I have a bit of spare time. This checkin makes rainbow a fairly complete implementation of arc, so if you're interested in trying out arc but need some of that ready-made java library goodness, rainbow might be your thing.

  java-new (class . args)
  java-invoke (obj method . args)
  java-implement (class strict . functions)

  on-key (component (var) . body)
  on-scroll (component (var) . body)

Java objects have the arc type 'java-object

  (type some-big-java-object)
  -> java-object

  (some-big-java-object 'equals another-big-java-object)

  (java-invoke some-big-java-object 'equals another-big-java-object)

  someBigJavaObject.equals(anotherBigJavaObject);

  arc> (set foo (java-new "java.util.HashMap"))
  {}
  arc> foo
  {}
  arc> (type foo)
  java-object
  arc> (foo 'put 'bar "toto")
  nil
  arc> foo
  {bar=toto}
  arc> (foo 'keySet)
  [bar]
  arc> (type (foo 'keySet))
  java-object
  arc> (foo 'getClass)   
  class java.util.HashMap
  arc> 

what's your project?

If you want your two web sites to be running with different domain names (www.mychurch.org, www.terrificrealtor.com), you have a couple options: you can run Apache (or any other HTTP server that can forward requests) in front of Arc, and be running two Arc processes, one for each site. Or you could hack Arc (or ask a hacker here to hack Arc for you) to look at the "Host" header.

Which lisp / web framework do you recommend?

True. When I search for "rainbow lisp", google asks me did I mean "rainbow lips". Rainbow's github page is the 6th result for "arc rainbow", alone among many discussions of the shape of the multicoloured atmospheric phenomenon.

Once we've taken over the world, I think it will get better.

> Merit of French

(And Otter doesn't seem to be going anywhere - no website, no new information for about a year and a half.)

  (= foo[bar] "value")

  (prn foo[bar])

  (= foo (table))
  (= foo!bar 123)
  (prn foo!bar)

  foo!bar

  ((foo 'bar) 'toto)

  foo!bar!toto

  (foo 'bar 'toto)

  foo[bar][toto]

Here's a macro that might be useful for digging down into a nested table:

  (mac dig args
   `(,@(reduce list args)))

  arc> (= x (table))
  #hash()
  arc> (= (x 'y) (table))
  #hash()
  arc> (= ((x 'y) 'z) 0)
  0
  arc> x
  #hash((y . #hash((z . 0))))
  arc> (dig x 'y 'z)
  0
  arc> (= (dig x 'y 'z) 1)
  1
  arc> x
  #hash((y . #hash((z . 1))))

Although it might be better to make a thread pool, where each Arc-side thread is a "task" (which will reschedule itself until it ends), much like how Erlang does it and how SNAP will eventually do it. This will allow you to easily launch and destroy thousands of Arc-side threads on a machine with far fewer cores.

This is the essence of Arc's 'load:

  (w/infile f file
    (whilet e (read f)
      (eval e)))

^^

SNAP would sidestep this largely by simply using bits of arc2c only as part of eval - basically eval is simply:

  (def eval (e)
    ((to-free-fun:bytecode-compile:arc2b-compile e)))

So SNAP will compile expressions one at a time.

Edit: It might be useful to add an optional parameter in some of the link-creating stuff where the programmer can add some sort of "hint" which the base system will use, so instead of http://example.com/a?fn=fkg34lk you get http://example.com/a?fn=voteup_fkg34lk

Or possibly just "make it long" and just have the base system add a number if the id clashes: http://example.com/a?fn=voteup-maybe-something-related-to-3

  arc> (= gs (uniq))
  gs2003

http://www.intertwingly.net/blog/2005/04/13/Continuations-fo...

A continuation behaves just like a one-arg function except it never returns to its caller. It returns to the point where it was created. This might upset the flow of the app server. Also, the app server relies on redirecting stdout to the network socket, and jumping to a saved continuation appears to restore stdout to whatever it was for that continuation.

I wonder if arc is intended to support full re-callable continuations - official arc only references 'ccc once, in the 'point macro, which is only used for 'catch. And the intent of 'catch (i think) is only to provide an escape mechanism, not a re-callable continuation.

i don't know what the OP is asking exactly, but the answer is likely yes. i implemented coroutines, so these more straightforward things should be no problem

i talk about it a bit on the blog post, but the problem with continuations is the freaken name. it sounds like some sophisticated thing, when in fact all it is is marking the next instruction. for example:

  (ccc func)

  (ccc [do (stuff...)
        (if blah (_ bleh)) ; early return
        (do more stuff)])

and because it's the next spot, and because you can call _ as a function, they refer to it with the holistic name "continuation," instead of "the spot after the ccc"

they could have just as easily made the primitive be mark-the-current-spot, a la:

  (ccc [= spot _])

fixed that for you ^_^ \/

For example, consider the minor problem of macros such as 'w/infile:

  (restartable
    (pr "Press enter to begin processing the file")
    (readline)
    (w/infile p "thefile.txt"
      (whilet l (readline p)
        (when (is l "foo\n")
              (prn "A \"foo\" was found in the file!")
              (prn "Please correct these errors first")
              (restart)))
      (prn "finished processing!")))