yea for the REPL i'm not exactly sure. i think it would have to be limited to 1-liners. for multiple lines then you'd have to use outer parens. where it would get wack is, say, copy & pasting code into the REPL, and if that code isn't using outer parens, how would it be parsed? it wouldn't be a problem if it was pasted and read in a 'chunk', but i think in my console it's pasted line-by-line or parsed line-by-line as if manually input. i'm not sure. hmmm. we might have to say "use outer parens if you're going to paste the code into the REPL"
however, that's the behavior as it is now in the scheme REPL. a custom Arc REPL would be able to handle things like pastes appropriately (maybe. i'm not familiar with console mechanics, but even if it wasn't 'purely' possible, a timer could be used so that if the delta between the last and currently entered lines is less than X, then it would be safe to assume the sequence was pasted)
for infix math it might be best to have a marker that says "the following form is infix"
#( (3 + 2) / 8 ) -> (/ (+ 3 2) 8 )
some other thoughts are notations for pattern matching/RE's
I'm really uncomfortable about making the repl and file readers differ, especially to the point of being incompatible.
About a custom console, I am not sure there is any reliable way to detect when a user has pasted code into the console. (That sort of thing is probably very OS dependent.)
Even if you did set up a timer like you propose, what would it do if the user recalled some lines from a multiline entry in history? I think most consoles would only pull up one line of history at a time, so the user would have to go through each line and enter it individually. And the timing would be such as to be indistinguishable from direct input from the user.
As for infix math, if you created an infix marker like