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
Figure I might as well post this here as well:

Numbers _are not_ functions! This kind of attitude is what gets you python's list formatting operator:

>>> "%s" % ("a string",)

'a string'

>>> "%s" % ["a string"]

"['a string']"

I've been burned by that before, and I'm not exactly stupid.

(I don't think this posted the first time. Forgive me if this turns out to be a double.)

edit: Bah, I can't get this code to format properly. How's that for ironic ;)

>>cwarre+xt8
Arc seems to take a very implicit approach to things - rather unlike Python. I haven't written anything non-trivial in Python, but it looks like the problem with the list formatting operator is that it's an infix operator that depends on similar looking characters (paren and square bracket) for its syntax. I think it might be less confusing as a function or method:

 list_format("%s", ("a string",)
 list_format("%s", ("a string",)
 ("a string",).format("%s")
 ["a string"].format("%s")

Looking at it on the screen, making it a method call looks far less confusing. Arc treating constants and sequences as functions doesn't seem like the same kind of thinking to me.

>>Zak+Ot8
Perhaps I should've elaborated a little. Here's a follow-up that I posted on reddit:

both of them violate the user model in subtle ways[1]. Most people don't expect numbers to act as functions. If a bug crops up because of it, more than likely they won't check to see if that's the problem. Again, I'm not against brevity. Just don't make functionality implicit in situations when the programmer isn't expecting it. If you use it so much, use a symbol prefix like `--I don't care. Just make it explicit.

In python's case, it's because it treats tuples and lists differently. Tuples and lists are almost always identical in python. The user's assumption is that they will also be identical in this case, when in fact they aren't.

[1] User interface design is surprisingly helpful when designing programming languages. It's fairly obvious why, but most people don't realize it.

>>cwarre+Pt8
Arc is supposed to be a LFSP. Smart people adjust their user model to the tools they have available (right?), so it's at least consistent with Arc's design principles.

It's not the choice I would've made - I tend to agree with you that "explicit is better than implicit". But languages all have to make certain assumptions about who their users are (same with UIs, really), and this design decision is consistent with Arc's previously-stated design philosophy.