App Engine is a distributed web server, so you can't save a closure in memory on server A and have your next request handled by server B. I believe the only options are storing the closure in the distributed memory cache (memcache) or in the distributed persistence store (datastore). In either case you need to be able to serialize the closure.
Yes, Jarc works with AppEngine. I've been learning AppEngine the last week or so. The CGI-style JarcServlet in the current release, jarc2, isn't an efficient way to go for AppEngine, so I've written a new JarcServlet that loads a single .arc file at init time which defines methods for each URI. I haven't done a new Jarc release, but if you pull the code from CVS, you can get the new JarcServlet. See webapp/servlet.arc for my test code.
> Jazzdev, where is the 'pr behaviour problematic?
I'm writing an HTML package. I'd like it to work as follows:
(html
(body
(somesetup)
"Some text"
(pr "Some more stuff")
))
I'm experimenting with the idea that calling pr shouldn't be necessary, so the tag expansion eval's everything and if it gets back something non-nil then it pr's it. I'd like to still allow pr to work also, but since it returns non-nil then some things get output twice.
I want the user of the HTML package to use standard stuff, so having prnil is awkward. Allowing pr inside these tags isn't necessary. I'm just playing around and trying to see what feels natural to use.
Using pr to print something without changing the semantics of a functional program makes sense in theory, but in practice it doesn't see useful. Have you ever actually done it?
I've looked at Rainbow. Continuation passing style!
Very clever. You get first class continuations and
can optimize tail recursion.
My next thought was to write a compiler to .class files
to improve performance and optimize tail recursion.
Not sure if this road will lead to first class continuations. I'd like to do stack copying for
continuations, but
I don't yet know if that's possible in the JVM. It
might not be.
Since you've already
done continuation passing style in Rainbow, I think I'll
stick with my plan to work on a compiler next.
There is a continuation library for java at http://rifers.org/wiki/display/RIFE/Web+continuations - but it's wrapped in a web server. Apparently it does all the stack copying for you. I looked at it briefly and ran away fast. But it might be the right approach if you're compiling to bytecode, and bytecode compilation is probably the only way to make arc go fast on java.
Rainbow's continuation-passing style means arc code is not using the native java stack, which probably slows it down immensely.
I doubt a stack copy is very feasible. For one thing, it would need a potentially different implementation from JVM to JVM (and from context to context, since a JVM might optimize something in several different stack-involving ways depending on which is best at the time). Also, based on what I see at http://www.cs.princeton.edu/sip/pub/oakland98.pdf and http://www.ccs.neu.edu/scheme/pubs/cf-toplas04.pdf, it looks like swapping out the stack would blatantly undermine the security model of JVMs that rely on stack inspection, meaning that lots of JVMs are probably actively motivated to keep native code from getting at the wrong part of the stack. Then again, I haven't actually tried it, so maybe I'm just being pessimistic.
In any case, stack copy isn't RIFE's approach. RIFE's approach is to use a custom ClassLoader on selected classes (classes implementing a particular interface) to transform the Java bytecode into explicit continuation-passing style at runtime. Ultimately, it does nothing the Java programmer couldn't have already done by writing those particular classes in continuation-passing style to begin with. If I'm already committed to having a continuation-passing-style Arc interpreter in my Java project, I can just do my to-be-CPS-transformed code directly in Arc and be done with it.
On the opposite side of the spectrum, JauVM (http://jauvm.blogspot.com/2005/07/so-what-does-it-do.html) has an approach I think is about as comprehensive as it gets. The idea is that it's a wrapper of an existing JVM, delegating just about everything except exactly what it needs to do in order to provide first-class continuations. Unfortunately, I think JauVM does this by directly interpreting every instruction, so it's probably horribly slow.
I think the best approach for Arc-in-Java is ultimately a compromise between RIFE and JauVM: A ClassLoader that's used for everything and CPS-transforms it unless it's a specially-marked class whose programmer is prepared to manually pass continuations.
Can't seem to get it to run. Where is rainbow.arc?
% ./rainbow.sh
Buildfile: build.xml
compile-parser:
compile:
jar:
BUILD SUCCESSFUL
Total time: 0 seconds
Unable to access jarfile /Users/jd/tmp/rainbow/build/dist/rainbow.jar
% java -jar build/dist/rainbow/rainbow.jar --strict-arc
Exception in thread "main" java.io.FileNotFoundException: Could not find rainbow/rainbow.arc under [.]
at rainbow.Console.find(Console.java:125)
at rainbow.Console.loadFile(Console.java:133)
at rainbow.Console.main(Console.java:41)
Okay, I found rainbow.arc. (I was doing find from the wrong place). And am following the README, but still no joy.
% setenv ARC_PATH ~/tmp/arc:./src/arc
% java -jar build/dist/rainbow/rainbow.jar
Exception in thread "main" rainbow.ArcError: call* table not found in environment: if you are not using anarki please specify --strict-arc on the command-line
at rainbow.vm.continuations.FunctionDispatcher.anarkiCompatibleTypeDispatch(FunctionDispatcher.java:68)
at rainbow.vm.continuations.FunctionDispatcher.digestFunction(FunctionDispatcher.java:52)
at rainbow.vm.continuations.FunctionDispatcher.onReceive(FunctionDispatcher.java:38)
at rainbow.vm.continuations.ContinuationSupport.receive(ContinuationSupport.java:28)
at rainbow.vm.Interpreter.interpret(Interpreter.java:30)
at rainbow.vm.continuations.FunctionDispatcher.process(FunctionDispatcher.java:33)
at rainbow.vm.ArcThread.run(ArcThread.java:28)
at rainbow.Console.compileAndEval(Console.java:149)
at rainbow.Console.load(Console.java:140)
at rainbow.Console.loadFile(Console.java:133)
at rainbow.Console.main(Console.java:39)
If you are using anarki and still getting this error, then it's a mystery. It might be necessary to expand "~/tmp/arc" into a full path - I know rainbow doesn't expand "~", and I don't know if the shell does. And "~/tmp/arc" should contain arc.arc and the usual arc files from the distribution.
Competition can be good, but I'm open to cooperation. You can send email to my jazzdev gmail account. I've avoided looking at rainbow until I got Jarc released. Now I'm curious to see what you've done.
Rainbow is 2x faster than Jarc, and first class continuations are impressive!
Of course! It came to me in my sleep. The standard scheme
solution:
Possible fix #5: local methods
(def debugger (stack env)
(with (run t framenum 0 framecnt (1- (len stack)))
(def repl ()
(while run
(print)
(let it (read)
(if (is it 'q) (set run nil)
(is it 'u) (up)
(is it 'd) (down)
(is it 'f) (goto-frame (read))
(is it 'e) (eval-in (read))
(is it 'b) (backtrace)
(pr "Unknown command: " it)))))
(def print ()
(pr "\n" framenum ":\t" (car (nth framenum stack))))
...
(repl)))
This is even shorter because I don't need the outer environment
to hide the helper functions from the global environment. Duh!
Why didn't I see this sooner?
There we are, closures to the rescue :) Careful, though; remember that what you define with def will be accessible throughout the entire program. Use let or with for local functions. (I can't tell what you want there, but that's tripped people up on these fora before.)
