Haskell chooses this order because partial application and pointfree style are really common.
let squareall = map (^2)
squareall [1,2,3] ===> [1,4,9]
squareall [3,4,5] ===> [9,16,25]
let f = foldr1 (+) . squareall . filter even
f [1,2,3,4,5] ===> 20
But since partial application is not a default behavior in Arc ([map square] and [map _ square] are not that different from one another) the order of the fn and list aren't as important.
Rule of thumb might be: put the fastest changing piece last, but this syntax thing might be a stronger heuristic.
pg said he is planning on opening up intrasymbol syntax and, presumably, presymbol syntax as well. Once that's there this is a trivial addition to play with.
But when? That may be the single biggest change I want, actually--much of the rest is implementable within Arc, but this is not. Certainly, when that happens this is trivial, but it hasn't yet, and there's no inkling of when.
This feels more like it's a step toward iterate instead of loop. The semantics of iterate always seem simpler, cleaner, and more lispy. It also seems like you can nearly roll your own with macros like these
I can't think of a good reason why it should vanish in any browser. Check to see that the text itself is actually gone and not just the same color as the background?
The only vanishing bugs I could imagine are either having it get shoved behind the textarea or being the same color as the background.
Skill++ is integrated into Skill. I actually mostly program in Skill++, but distinction is lost on my fellow engineers anyway, who don't even understand the code == list concept. Skill++ is based on Scheme while Skill is based on an old Lisp, Franz Lisp I think, with dynamic binding. Skill can call into Skill++ and vice versa; Skill is a Lisp-2 while Skill++ is a Lisp-1; the namespace used in Skill++ is the function namespace of Skill.
