Obviously, () is not an arc-list (as defined above). Thus, the test (all arc-list? args) fails with (+ '(a b c) ()) : finally, (apply + args), which is the numerical + of scheme is applied, hence the error message.
In fact, both were needed to optimize things. Mzscheme's doc says explicitly (though I can't remeber where exactly) that standalones are a little faster than interpreted code (there are a few more optimisations they can perform during compilation I guess). Running arc1.scm through mzscheme -f is a little slower.
There is an initial overhead for byte-compiling the code
and jitting it -- but that's not something that you'd be
able to measure for such a small piece of code. Once
that's done, it's the same code -- mzscheme (since a good
while ago) on intel and ppc does not interpret code. Ever.
Even on solaris, where the jit is disabled, it's
"interpreting" byte-compiled code, so it is not an
interpreter in any case.
Well, it's on the git now. To have the executable, just run
mzc --exe arc1 arc1.scm
If you feel adventurous, mzc --gui-exe arc1 arc1.scm might give you access to MrEd, the graphical library of MzScheme (a MrEd binding to arc could be a nice thing :) but I didn't try it.
Very nice. Both your suggested commands worked for me (on Windows XP).
I like the GUI especially (it actually solves a bug I found with mzscheme that was stopping me from pasting code directly into the command line). Although I find it somewhat strange that I have to click quit twice in order to actually close the program.
Well, maybe I didn't fully understand how to use it, but it is really too hard for me to write a code that looks like "dup rot- . * + dup dup < . if", even for low-level functions.
I find myself taking too much time thinking "let's see, the value I want is at the third position on the stack, I want to get it duplicated on the top, but without changing the order of the other elements, so I should do..." instead of really solving the problem I'm working on.
But in other languages you don't even have to bother with that. Accessing the third element of the stack is easily feasible and you can even guess how to do it.
And the fact that my variables have no name (they're all called "first element on the stack", "second element", etc.) reminds me assembly code, but without the efficiency : I can understand that in a low-level language as Forth, but it doesn't look like Factor is one.
But I can be wrong, and anyway Factor is on my "try it again later" list.
On the one hand, factor -does- have named variables.
On the other hand, once you start experimenting with stack stuff there's a moment where you go "aha" and it actually starts to make a lot of sense for temporary variables.
There are probably other aha moments further in that I haven't got to yet; I've not spent as much time with factor as I want to.
I dunno if I'll ever use it for "real stuff", but I think it's worth fighting your way through to the aha moments just like lisp and haskell are even if you never expect to use -them- for "real stuff".
After a little adventure getting git to work, I added my code to the git repo. (Being new to git, I didn't know you have to add before you can commit, and you have to commit before you can push....)
Everyone feel free to make improvements as you see fit.
If I remember, the very first version of Python was 5 x slower than the next one, which was itself many times slower than the current ones. Well, obviously, Arc1 is much faster than Python 1...
And if you want good news, compare it with Groovy or Squeak...
Interesting. I suggest you add defsop to the arc-wiki.git
As for the process that does the archiving... if I remember correctly hacking through srv.arc shows that it will summarily kill any operations that take too long.
Well, concerning long threads... That's the reason why I fix threadlimit* at the beginning to 300 s. That's enough for archives 5OO MB long, and anyway, for even bigger archives, I wouldn't propose people to use this method...
