zlacker

>>pg+(OP)
Better display of source code in comments

>>vegash+0i
You can now include code in comments:

 (def codetree (file)
   (trav + 1 (readall (infile file))))

Anything that appears after two newlines and a blank space is treated as code, till there's a line that doesn't begin with a space. This is like the markdown convention, but you don't have to use four spaces; one will do.

Incidentally, the code above tells me the number of nodes in the code tree of a file. Not just leaves, which would be

 (len (flat (readall (infile file))))

but interior nodes as well. To me this is the best measure of how long a program is. I used to go by lines of code

 (def codelines (file)
   (w/infile in file 
     (summing test
       (whilet line (readline in)
         (test (aand (find nonwhite line) (isnt it #\;)))))))

but I found this was encouraging me to do the wrong things.

(This kind of test matters because I'm constantly trying to make news.yc shorter as a way of pushing functionality down into Arc.)

Here's trav, btw:

 (def trav (f base tree)
   (if (atom tree)
       (base tree)
       (f (trav f base (car tree)) (trav f base (cdr tree)))))

It traverses a tree, doing something at every node. So e.g. CL copy-tree would be

 (def copy-tree (tree) (trav cons (fn (x) x) tree))

If you're wondering how the second argument to trav in codetree could be 1, it's because a constant when called as a function simply returns itself. This turns out to be quite handy.

>>pg+Dq8
Is Arc going to support concurrency and/or manycore systems?

The original writing(s) on Arc assumed a free lunch that would continue for decades (justifying a lack of emphasis on scalability and efficiency in implementation, I thought), which already seems kind of naive. You can already buy 8-core systems from Apple, mang. It's the future.

>>hennin+9r8
It has threads and a way to say a chunk of code should be executed atomically. No more than that at the moment. Nor is there any explicit notion of a processor. I'm not sure how that will turn out.

>>pg+cr8
I think that's all you need for version 1.0. All the bleeding-edge concurrency abstractions like software transactional memory are only that: abstractions. Henning is right that they're going to become increasingly important in the future, but as long as you have threads and atomicity as building blocks, you should be able to do all the rest in the macro system.

Just make sure that some concurrency package eventually becomes a de facto standard. Getting C libraries that use different threading implementations to interoperate is a nightmare, and I'd hate to see Arc go the same route.

>>dfrank+qr8
In general, combining multiple packages that each attempt to perform concurrent operations is error prone, especially if they use locking. The STM papers make an interesting argument for why using transactions rather than locks as the typical concurrency primitive leads to concurrent programs that can be more easily composed.

>>neilc+1t8
That's why it's really nice to see that Arc has threads and an atomic-execution mechanism. GHC-style Software Transactional Memory would be a natural fit, and it seems to scale very well.

Locks seem to be on their way out.