Arc Forumnew | comments | leaders | submitlogin
2 points by hjek 873 days ago | link | parent

For making small self-contained binaries, Embeddable Common Lisp[0] and Chicken[1] are great. Gambit[2] is also worth a look, and while it's supposedly faster than Chicken, Chicken does have way better documentation and more packages available.

Guile, Picolisp and Arc can't make self-contained binaries, right? But Ferret looks interesting.




3 points by shader 872 days ago | link

True, Guile and Picolisp do not make self-contained binaries, but they're pretty lightweight and fast, and seem like they still might be half-decent choices. I guess I should probably remove Guile from the list of candidates, since it's really for plugin extensibility in other programs; I may even have been slightly overlapping it with Chicken in my mind.

Arc would have to be "polished" a bit to make it work, but that's what we're here for, isn't it?


2 points by akkartik 872 days ago | link

I'm not sure system programming is a good domain for Arc. Why not just Racket directly? The interpreter makes Arc quite slow.


2 points by shader 872 days ago | link

Yeah, I probably wouldn't use it for that either, at least as much because of the relative instability and hackishness of arc. It was fun for a few minutes to imagine modifying it to be used that way though.


2 points by rocketnia 871 days ago | link

Interpreter? Are you talking about Racket's bytecode interpreter?


1 point by akkartik 870 days ago | link

No, I was forgetting that ac is considered a compiler :) But it compiles the Arc codebase every single time Arc starts up. Maybe we should start memoizing its outputs to disk somehow, see if that makes it noticeably faster. My suspicion is egregious runtime processing like ar-denil-last and ar-apply-args will cause it to not make a difference.

Given the pervasiveness with which Arc has to make such transforms at runtime, I've gotten into the habit of thinking of it effectively as an interpreter.