In all the Arc code I've written so far, I've used map a lot. That's probably quite common for anyone programming in a language based on lists. I therefore propose that Arc have a special syntax that turns a normal function into one that maps over a list.
(def $ (x . lists)
(if lists
(apply map x lists)
(fn (lists) (apply map x lists))))
More or less does what you want, without special syntax.
($$car... would have to be written ($($ car)... though.
To me this looks like a specific case of wanting currying/partial application built in for functions of semi-fixed arity, rather than a need for new syntax.
You can even be cleaner: $car is $.car (though this doesn't work for $.$.car). But I don't think this is really a specific case of partial application (though I see where you're coming from). While partial application would be ((map car) '((1 2) (3 4) (5 6))) and this would be ($car '((1 2) (3 4) (5 6))), the biggest win (for me) is not the partial application aspect, but the conciseness of having just one character, as opposed to (currently) ([map car _] '((1 2) (3 4) (5 6))) or ([apply map car __] '((1 2) (3 4) (5 6))), or even the partial application version. And even so, this strikes me as more similar to a request for explicit partial application, which is already implementable, than implicit partial application.
Yes, it was the conciseness I was after. The syntax was inspired by K, where you can do this by putting a ' before a function name.
Of course, K often looks like line noise, but then K takes this technique to its logical conclusion and uses special syntax for everything. There's no need to go that far.
I dislike this idea, mostly because the syntax is pretty trivial anyway using the bracket currying suggested elsewhere. [map car] isn't much shorter than $car, and it's much more flexible and leaves $ (or whatever symbol might end up being used) open for some other meaning. It's also more explicit, although I'm not sure that's worth much.
That's not necessarily true; as I pointed out further down (http://arclanguage.org/item?id=4704), you can get the effect you want. On the other hand, you do take a speed hit. I'm inclined towards supporting both, but swapping the args is very easy to write and may not belong in the core.
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.
I really like this idea, but I don't know that $ is the best choice. On the other hand, I can't think of something better... ^car? &car? At any rate, fantastic idea.