We could use any unique value that compares equal to itself with "is" but isn't the same (by "is") as any possible value read from the input file.
An example of such a value is "(list 'a)". This creates a new pair (cons cell), which "is" itself, but "isnt" any other pair or value.
Another example is in Arc 3.1, fn returns a new #<procedure> which "is" itself but not any other function or other value.
"[]" expands into such a function, so it's a cute way of getting a unique value.
However, for web applications it would be nice if closures could be serialized (written out to a file and read back in later), so that a server could be restarted without losing user's state.
If this were possible, then "[]", which expands into "(fn (_) nil)", could be written out to a file and read back in later.
Even if we could read in serialized functions, using [] as a sentinel value would still work if every evaluation of (fn ...) continues to produce a new, unique function, much like how "(list 'a)" or "(cons t t)" produces a new, unique pair every time.
Or maybe it would be useful for optimization or for some other reason for two identical functions "(fn (_) nil)" to evaluate to the same function object, much like how every time we read in a symbol 'x it evaluates to the same symbol. Or not... that might be a useless optimization (at least, I can't think of a use for it off the top of my head). But that was my thinking behind "maybe not []".
Incidentally, app.arc creates a unique "fail" global variable in this way. (Eeeeeaaaaaargh, never use asterisks in text. The word "fail" has an asterisk at the end. Is there a way to escape asterisks?)
; (= fail* (uniq))
(def fail* ()) ; coudn't possibly come back from a form
You've even italicized the reply button. :-p I think the only way to "escape" an asterisk is to put whitespace after it: If you put a space at the end of "fail* ", presto. You could also subtly tweak your style in order to write fail* without quotation marks or other punctuation afterward. But yeah, escaping would be nice.
I suspect that if we want to be able to produce unique symbols that can be serialized, we should use random symbols of sufficient length that the chance of collision is vanishing small (that is, similar to a UUID or GUID).
While a #u:X approach would work for a single output, if I produce multiple output files I have no reliable way to put the same uninterned symbol in different files.
and doesn't read the scheme symbol syntax in all its hairiness
I agree with this decision; it's useful to be able to write an arbitrary symbol and have it read back in again as the same symbol from that canonical representation; but we don't need to support every Scheme feature that happens to be visible from Arc...
Compile into binaries: what's the end result you care about?
To run code without the interactive console, in pure arc3.1 one way to do it is to add calls to load your own code in libs.arc. Iirc some people have also made extensions that allow you to run Arc code from the command line, I don't have a reference in front of me but you might try searching the forums or looking in Anarki.
I mean 1) if I want to run a web app I don't want my server to depend on an interactive console, I want to run it (them) in the back and stop and start them and ... 2) if I want to run something on a host or a cluster (neither usually have the interactive console, so a binary could help there
In other words, can you give me some use cases that I can understand how you develop and deploy arc apps?
By the way the documentation link in arcfn.com is what I was missing, thanks.
I like using the "screen" program (available on most servers, try typing "man screen"), which lets me pop in and see any error messages.
For an automated startup, you might try something like this shell script (after modifying libs.arc to load your code):
#!/bin/sh
cd /location/of/arc/directory
nohup mzscheme -f as.scm >log 2>&1 &
a caveat here is that "nohup" redirects stdin to /dev/null which in turn will cause Arc to go into an infinite loop if it gets to its REPL, a trick is to have the last thing called in libs.arc be "(serve)" (or "(asv)" etc.), which doesn't return and thus Arc won't get to the REPL prompt.
Thanks, I use screen all the time, still I fill there is a lot fundamental differences between ways of arc and ways of "bulb" (python for me) that I need to learn. By the way the idea behind Anarki is that people come and fork and if they did something worthwhile it could be merged back, right?
Yes, the main purpose of Anarki is as a place for people to share the work they've done on/for arc. Since arc itself is easily modified, a lot of the code on Anarki actually changes the language. There is also a fair amount of library developed there as well, though since most important library functions can be lifted from Racket that's not so much of an issue.
However, beyond simple bug fixes pg hasn't ever discussed much about changing the language itself with the community. As far as I know, none of even the truly good, simplifying and useful features of Anarki are planned to be lifted to arc.
iirc all reported bugs fixes were incorporated by the arc3.1 release. (Releases haven't always incorporated all fixes reported up to that point, the atomic-invoke fix was particularly alarming and took several releases to make it in).
The only bug I'm currently aware of off the top of my head in arc.arc is readline, which was reported after the arc3.1 release.
There are a couple of known issues with the Arc runtime (i.e. the queue bug you found which seems likely caused by unsafe mutation of immutable cells, nested quasiquotation) which have prospective fixes, but neither tested throughly enough that I'd personally say, "oh, why yes, you should go ahead and switch HN over today".
