I'm unsure of whether this would in the end be any more portable than a compilation-based approach. The only fundamental dependencies arc has on plt scheme are on some of its library functions; AFAICT, arc compiles down to fairly portable scheme otherwise. So IMO the best way to make arc portable would be to a) write an arc compiler in arc, b) explicitly separate out the library functions arc needs beyond core r5rs, and c) for each scheme dialect we want to port to, write a support library supplying this functionality.
That's assuming we even want to keep Scheme as the backend, though I don't have any better suggestion. (Well, not yet...)
> It would be portable except it wouldn't work on PLT Scheme, because of inmutable pairs. (isn't that irony?)
Well, arc itself now contains hacked-in mutability for plt's supposedly immutable conses, so that portability problem is fixed :).
Using nearlyfreespeech.net would not work for you anyway; although they support plenty of programming languages, they only support them as CGI scripts invoked by Apache, not as long-running processes which do the work of serving pages themselves, which is how the arc webserver works.
The only real options for hosting an arc webserver, as far as I can tall, are: host it yourself, colo it, or use a VPS.
Thanks for responding. It looks like the best choice for me is to host it on my desktop for now, hoping my internet connection doesn't suck enough to prevent it working.
I'm honestly not sure what you're asking here. How do most what output decimal format numbers vs. rational? And what do you mean by "decimal format numbers" - do you mean floating-point numbers?
Are you asking how to format numbers in a string? If so, take a look at 'num.
Don't get me wrong, I like the idea, and I'll probably incorporate the auto-detection of interactive terminals and relative load-path fix to anarki (we already have eof-detection, thank you very much :), but the implementation has a rather significant not-exactly-bug-but-nonetheless-undesired-effect: it assumes that when (tl2) exits, the arc process itself will die, so it doesn't call (exit) explicitly.
This assumption is emphatically not the case when mzscheme is run with the options I prefer (-mf for mzscheme 372, -qif for mzscheme 4); for when the arc (tl) quits, we drop down into mzscheme. This is extremely useful, and is the purpose of the (if (eqv? expr ':a) 'done ...) check in 'tl2 that you eliminate (you don't even comment it out!) with this patch. So, with your patch applied, a) there's no proper way to drop back to the scheme interpreter, and b) if you run arc with the scheme REPL underneath (the -i/--repl flag), it will not in fact exit on eof, but will drop back to scheme.
I have ported (and pushed) the changes your patch makes to anarki, with some modifications (avoiding the complaints I make in the parent post); while the actual changes are spread across several commits, a summary diff can be found at http://sprunge.us/SWVF?diff; note that this diff is not relative to arc3.1.tar, but to anarki before I ported the changes, so it will look a little different. I've also omitted changes to arc.sh, because they will be wholly unfamiliar to anyone not using anarki. Instead, you can take a look at the entirety of arc.sh, which is anarki's script for running arc, at http://sprunge.us/XPWN?bash.
There's a reason anarki has a stable branch. Of course, it's horribly out of date now, which is why I'm (still) working on porting some of the old arc2 anarki's more useful features to arc3, without the cruft. (The delays have mostly been caused by me dithering on what the best way of handling CatDancer's idea of keeping hacks separate is; I have most of the actual features I wanted to port done already.)
More accurately, a) I haven't ported it to arc3 and b) it hasn't shown up on anarki's arc3 branches last I checked. If anyone else has ported it, I'd be interested to know.
Have you actually run this code? It seems to have a lot of bugs. Also, this is just a style issue, but you seem to be indenting 8 spaces. Lisp convention is to put indents at 2 spaces, because lisp code tends to nest much more than code in C-like languages.
This is unnecessarily complex in two ways, and inefficient in a third. First, [alive? _] is just alive? itself. Second, the length of a list is zero if and only if that list is nil, and nil is itself a false value, so testing (is (len x) 0) when x is a list can be replaced with just (no x). Hence a simpler version would be:
(def doomed (u) (no (keep alive? u)))
; with ssyntax we can simplify this even further:
(def doomed (u) (~keep alive? u))
However, as mentioned by pg, this is still not the most efficient version of the function. If there are several alive cells in u, then (keep alive? u) will find all of them before terminating, when really we want it to exit with failure upon the first live cell it finds in u. Hence any one of (~mem alive? u), (~some alive? u) or (~find alive? u) will be more efficient (it doesn't really matter which you choose in this case).
As far as I can tell, your 'cindex function seems to be meant to take two integers and return a unique index. However, (cindex a b) == b + b*(a-1) == b + ba - b = ab. This obviously collides, for example, with (cindex b a).
You seem to use infix dot for accessing the fields of a cell a lot. This won't work; or example "c.fellas" will expand to "(c fellas)", which will depend on the value that fellas happens to be bound to (if any). What you probably want is "c!fellas", which expands to (c 'fellas).
(def aliveneighbours c (map [isalive _] c.neighbours))
; did you mean this?
(def aliveneighbours (c) (keep alive? c!neighbours))
I find them quite useful for my irc bot, although I do run into the problem of not being able to @-substitute a simple variable unless it's going to be followed by something not permissible in a symbol. In particular, colons will be parsed as part of the symbol, which is a PITA. There is a workaround for this, but it's ugly:
