I like the look of optional outer parens. It should be fairly easy to implement without too much complication with indentation.
I'm a little dubious about external symbols, though; they just don't look very Lispy to me. If these are to be integrated into the official Arc, I think we need to be sure of their worth. (The : function application operator, for example, doesn't look like it saves hardly any typing.) But if we got readmacro support in Arc, perhaps some or all of these could be implemented by users, inside Arc.
I don't particularly like the (4 * ...) because it interferes with implicit infix math (although others may not care about that as much as I do).
Piping just looks confusing to me; perhaps you could give an example of use?
The | as with looks like it could shorten code a bit, as it shortens the identifier name and removes one set of parens. But on the other hand, let could just be renamed to w/, and let could be made to not use an implicit do, in which case multiple variable assignments could be allowed. As an example of use:
(w/ a 'h b 'i
(pr a b))
I think this achieves the conciseness of the | form, and I don't think the transposition of places is very important in and of itself.
the nice thing about using multiple newlines as markers for new forms is we don't have to worry about indentation
those examples i gave for exterior symbols are just to show the sorts of things that could be possible. the 4 * notation for example would be completely out of place in Arc. (it's a notation that one of my LOGO languages uses.) the only example of those that i think is nifty is the | notation
though that piping could have some interesting uses. basically it lets you write functional statements in directed form rather than nested
(def a (x) (+ x 1))
(def b (x) (* x 2))
((a => b) 3) -> ((fn (x) (* (+ x 1) 2)) 3)
3 => + <= 2 -> 5 or [+ 5 _]
a b => + => [* _ 3] => [/ 1 _] => sqrt -> (fn (a b)
(sqrt (/ 1 (* (+ a b) 3))))
with the "implied underscore" form of [...]:
a b => + => [* 3] => [/ 1] => sqrt
sqrt <= [/ 1] <= [* 3] <= + <= a b
args within nodes:
a => [* 3] b => + -> (fn (a b)
(+ (* a 3) b))
so it's basically composition with some things to make it more general
i wonder what tomfoolery could be done by using the list as the format for the directed graph
anyways, i don't really know what i'm talking about wrt piping, and i don't find the notation very handsome. though it just occured to me that we can already just make a 'pipe' macro/function that would allow us to write things close enough to that notation. programmable programming language indubitably
and again, these are just heuristics for the most part. maybe with the small spark of these examples, other people can come up with some useful notations, or more useful sparks that may eventually lead to some :)
Oh, I didn't see your note about multiple newlines separating forms. That is an interesting approach, and removes the need for meaningful whitespace. But I have to wonder if it might get a little tiresome at the repl, since you would always have to add an extra newline to all your one line forms (unless you reverted to outer parens again).
And I now see what piping does, although I agree with you that the notation doesn't look very nice.
Perhaps external symbols could be used to do infix math? Although that might make it difficult to distinguish from when you want to do (for example):
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
