(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.Why 'whilet instead of 'while and why 'aand instead of 'and? I thought one of your aims was to produces a minimal set of "axiomatic" operators (functions, macros, special forms) which gave the maximum utility. So couldn't these be generalized into a single operator?
Also, isn't ")))))))" overkill for such a simple function, Can reader macros be defined within lisp? (like if you wanted to make } close all parenthesis up to the top level for example)
))))))) isn't overkill to Lisp hackers. Lisp hackers read code by indentation and rarely notice the parens, especially terminating ones. There have been dialects (Franz Lisp) that used ] to close off all open parens, but it would be a waste to use up a good char like ] to fix a non-problem.
The usual Lisp do macro, for example. What a wretched bit of language design. Even now, whenever I encounter one, I have to stop and translate it in my head. Plus it can be very verbose. The reason do is so bad is that whoever designed it wanted to make it as functional (in the no-side effect sense) as possible. But sometimes side effects are just the right model.
BTW, there is a do in Arc. It's the new name for what used to be called progn. (It's surprising how much better that little change makes code look.)