For outgoing connections: yep sure, as you can see you're not the first to want it ;-)
For select(): I, at least, would be a bit interested to see. It could be fun to write a srv.arc which uses it, the perf should be better (or not, it's a common misconception that select() will always and automatically make things faster + high-perf is not the goal for Arc anyway. select() should make the memory occupation lower, but to what I've seen MzScheme's threads are light enough memory is not really a problem). And with coroutines, maybe it could copy the vanilla srv.arc behaviour (maybe coroutines are not even needed, or not sufficient, I'm not a async IO expert enough to say. That's mainly why I'd be interested in having select(), I could try).
By copying the srv.arc behaviour I mean, when you're in a defop, what you print is sent to the socket, and when you return the socket is closed, which makes life easy.
Example:
(defop hello req
(prn "Hello!"))
Then go to localhost:8080/hello, and you'll see a blank page with "Hello!" written. Simple. As far as I know, async-IO-based code is often more complicated than that.
Last but not least, it's interesting because you'll certainly learn a lot writing it.
> How big is the chance of it being included in arc of the level of suckage is tolerable?
Fairly low. I mean, just for the heck of it, pg will not include (interesting) code. Your code would have to make the code of news.arc shorter or the perf of news.arc far better. Outgoing sockets, for instance, don't, this is certain.
Anarki is a kind of fork of vanilla Arc, and it includes, for instance, the outgoing sockets stuff by default. I don't know its codebase enough to say, but maybe there are other interesting network code. Anarki is at http://github.com/nex3/arc
Also, maybe browse/search (http://af.searchyc.com/, site:arclanguage.org <searched terms, i.e: async IO> in google) this forum.
Interesting. I had thought the purpose of HN was to push down on arc and make sure the language was capable, thus improving arc. Now it seems that arcs only purpose is make HN code work?
I'm seeing chickens and eggs fly by at hazzardous speeds.
Maybe I am reading this wrong?, but it seems to be a common response/statement.
I suspect that if you want to know about Arc's design goals, then pg's writings at http://www.paulgraham.com/arc.html is a better source than various random interpretations floating around on the forums.
Agreed. I do hope, however, that arc.v4.0 is structured in such away to move away from being news.arc centric. I hope pg chooses a different project to push down on arc. I think this would open the door to a fresh perspective.
