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
As far as you're thinking in procedural mind, probably there seems to be a big difference between constants and procedures (functions).

Once you are converted to functional mind, difference between a constant and a function that returns a constant is very subtle. When you use combinators a lot, you no longer think functions as something "invoked" or "called" in the similar sense as in procedural languages.

A possible pitfall in this case is that Arc is dynamically typed language. I usually program in Scheme, but when I'm passing function-returning-function-returning-...-functions around a lot, sometimes the 'one-function-level-off' error becomes hard to track down. Implicitly promoting a numeric constant into a constant function possibly delays catching this bug (since it masks the function level difference) but I doubt that it makes situation much worse. I think optional type declarations and type inference would be a lot of help.

>>shiro+7u8
It's not really a procedural vs. functional distinction - I'm fluent in Haskell and had the same initial reaction as cwarren. Rather, Arc is "weakly typed". The same bit of program data can be interpreted as different types depending upon the context where it's used. (This is distinct from strong-but-dynamic-typing like in Scheme or Python, where you have to explicitly convert between types.) It joins the club of Perl, PHP, and assembly in this regard.

I mentioned elsewhere on this thread that I think this is the right design decision given Arc's design principles, but that those design principles are flawed. In my experience, bugs resulting from implicit coercions are rare, but they're also really difficult to track down. That was a major reason I switched from PHP to Python.

>>nostra+sw8
OK, I stand corrected. Statically-typed minds also frown on this. It might be only Lispers that feel differently (after all, they've been conflating an empty list, a boolean false, and a symbol NIL and insisting it's the right thing).