(def codetree (file)
(trav + 1 (readall (infile file))))
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))))
(def codelines (file)
(w/infile in file
(summing test
(whilet line (readline in)
(test (aand (find nonwhite line) (isnt it #\;)))))))
(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)))))
(def copy-tree (tree) (trav cons (fn (x) x) tree))
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)
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.
))))))) 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.
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.
I thought a sequence at a procedure position acted like aref, e.g. ("abc" 1) => #\b, right? So the automatic promotion of constant to constant-function occurs only for non-aggregate types?
I love the idea of startups, but I've got the wanderlust. During the part of the year where I have net access, I watch ycombinator closely, and I'm not really hoping to see startup news.
In On Lisp, you mentioned that implementing continuations with closures via transformation to CPS could be accomplished by writing a code walker, but that this would be a "serious undertaking" in Common Lisp.
This struck me at the time and ever since as painful, but understandable. Macros aren't first-class objects in CL, so the code you're walking through could be very complex due to macro-expansion, and I could be wrong, but I don't remember if the resulting code would necessarily contain clues that tell us what macro generated it, etc.
Could one assume (and it is definitely an assumption, or speculation, not a deduction from what you've given us here!) that it would be much simpler in Arc? Say, a page or so of code?
I'll stop asking questions now. I feel I'm reaching the limits even of assumption and might start getting silly. (For instance: "Could I write a function that let me select nodes within a loaded function using CSS Selector syntax?", but that's just silly so I won't ask it).
Sorry for asking obtuse questions obtusely. Let me try this way:
How much would codetree need to change to accept a function or macro as input instead of a file, and produce output that is similarly meaningful? (Not at all, a little bit, a lot).
Sorry again for poor question quality, and to harp on what increasingly appears to be an unimportant point.
Why "atom" instead of "leaf"? Especially since you acknowledge it's a "tree"?
(isnt it #\;)
(when (and (regex-match "[0-9]" foo) (is it 4))
(print "it is 4"))
Unset variables are not null; that would lead to horrible bugs. But I don't think boundp exists either. So far I haven't needed it.
Edit: aand binding test results to "it" reminds me of Apple's Hypercard. I will read the entire thread carefully before asking questions next time.
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 ;)
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.)
list_format("%s", ("a string",)
list_format("%s", ("a string",)
("a string",).format("%s")
["a string"].format("%s")
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.
I don't know why this is surprising (though I don't dispute that most people find it so). I think both Python and Arc pay a lot of attention to this principle, though their philosophies on the subject are quite different. I agree that allowing constants to be called as functions could be a source of bugs. It also seems like it could be, as PG says "quite handy". I'll have to see for myself when Arc is released.
Locks seem to be on their way out.
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.
"%s".format("a string") #yields: a string
"%s".format(["a string"]) #yields: ["a string"]
"%s".format(("a string",)) #yields: ("a string",)
http://research.microsoft.com/~simonpj/papers/lw-conc/index....
(The paper is also notable for giving a complete operational semantics of the system it discusses.)
(But this stuff isn't in GHC mainline, and won't be, for now, because it needs serious performance work first.)
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.
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.