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))

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))))

  a b => + => [* 3] => [/ 1] => sqrt

  sqrt <= [/ 1] <= [* 3] <= + <= a b

  a => [* 3] b => +      ->     (fn (a b)
                                    (+ (* a 3) b))

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 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):

  (map + '(1 2 3) '(4 5 6))

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 )

  @([aA][rR][cC])

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

  #( (3 + 2) / 8 )

  (# (3 + 2) / 8)

  (foo ,@([aA][rR][cC]) ,baz)

  (foo ,@([aA][rR][cC]) ,baz)

Significant indentation is great. Wait, come back! Don't put this in the language yet! I'm not done! Significant indentation is great for languages like Python, in which code blocks are different from expressions and never go smack in the middle of a function call.

No, it's common sense. Call me old-fashioned, but I prefer being able to tell if code is syntactically correct just by looking at it instead of having to perform a hex dump. Never mind being able to reconstruct indentation from syntax when it eventually gets mangled in email/forum postings/code restructuring.

> Have you ever coded in Python?

Yes I have. Apart from the above caveat it's quite a nice language, although I find Ruby more elegant.

> Need I remind you what happened when Larry Wall tried to combine all the great ideas from a bunch of different languages into one?

> No, it's common sense. Call me old-fashioned, but I prefer being able to tell if code is syntactically correct just by looking at it instead of having to perform a hex dump.

Are you trying to say that source code (either with or without meaningful indentation) requires a hex dump to read? Or are you talking about object code (in which case I am pretty sure indentations is entirely irrelevant).

>> Need I remind you what happened when Larry Wall tried to combine all the great ideas from a bunch of different languages into one?

> Yes, it got hugely popular. You got a problem with that?

I don't know about you but Perl's conglomerate syntax, combined with all that extra magic, makes Perl pretty unmanageable in my opinion after a couple hundred lines of code.

From pg's essay Arc at 3 Weeks:

I am aware of some rather horrid languages that forced the use of meaningful indentation, but that doesn't make indentation evil in and of itself.