Seems to me the current meaning of a:b.c is not practical in real code and might be wasted semantic space- Although I'd be happy to be corrected and shown that it is actually useful, if someone disagrees.
(I'm sure everyone appreciates my use of reddit-style "vote up" links... pretty soon the arc forum will be overrun with Ron Paul stories :-)
I don't know what to think about all this syntax. I think it is fine for pg to look for ways to make Lisp more concise and parens-free cuz he is a master of Lisp. But is everyone piling onto this experiment as savvy about the benefits of those parnes? Or are some just trying to turn Arc into C to get back to their comfort zone?
As for it being optional, the danger I see is that this punctuation stampede is encouraging noobs in their fear of parens. The fact is, anyone who gives Lisp a serious try never ends up in week two saying damn Lisp rocks but how do you people tolerate those damn parentheses!!??
That said, I did as much punctubreviation as I could doing Arccells and I did not hate it. Time will tell....
The problem is that instead of learning Lisp/Arc people are spinning their wheels trying to design it. I see very little sign here of people actually programming in Arc. If pg had just laid down the law folks would be using Arc instead of trying to fix a language whose excellent heritage is unknown to them. But I think some good ideas came out of the first wave of suggestions so I am undecided on the merits of the dictator's three-microphone town meeting.
"won't have anything worth releasing for months..."
Er, um, dude... it's Lisp, you are supposed to be able to release it every day. Please don't tell us you are still running the system specification document past the user acceptance committees.
Well, I do not totally agree with you there. I have programmed in Arc both for fun and work, and have also coded in Scheme a little, and I really find the . and ! syntax is really a good thing for structure access, mainly when you have nested structures. You know, when you have 3 or 4 opening parentheses at the same time. Too sad you can't fully use it in these situations.
But it's not a problem of fear of parentheses ; actually I couldn't find other cases where . and ! could be used without feeling a bit ugly (i.e. in calling functions or macros). Yes, parentheses & s-exprs are great, but I don't believe they should be the only syntax for accessing structures.
Don't worry anyway, I don't think Paul would integrate suggestions he considers weak, even if many of us asked it.
i have to most respectfully disagree friend. so far i like most everything i see in arc, but this ssyntax business does not resonate well with me. i thought it was only me (i'm getting old and all) but now i see some other people that are bothered by it so i feel i should say something. i think there is something to this.
I think there is way too much discussion on this forum of new syntax without much clear gain. It's rather overwhelming listening too and I'm afraid it will make arc much more difficult to learn if it all gets adopted.
You have a point, but let's distinguish between optional syntax (like : ' !) and mandatory syntax (as is used copiously in most languages)
Optional syntax has far fewer minuses, I would argue- New users wouldn't need to use it if they prefer not to.
Also, we're not talking about increasing syntax here, just using the existing syntax in a different way.
My personal thinking, though, is that it would be OK to go all out with the other special characters to generate optional syntax, as long as it is really, really, really well thought out. (other arc users, such as yourself, would probably disagree with this argument, however) Some special character for currying (such as described in the current arc.arc comments) would be a strong plus, I think.
the problem is that people will use it. i don't want to read through a:b.c code. my eyes are already optimized for (a (b c)) and i like it thank you very much.
I think that if a:b.c means anything, it should be (a (b c)). I can understand that : is normally right-associative, i.e. a:b:c:d means (compose a (compose b (compose c d))) rather than (compose (compose (compose a b) c) d). However, it's really counterintuitive that a:b.c currently means (compose a (b c)) rather than ((compose a b) c).
While I agree wholeheartedly that "Should the programmer be allowed to...?" should be answered "yes" as much as possible, the a.b syntax confuses me. While it's totally understandable that a.b means (a b), it's weird that a.b.c means (a b c).
I like the function composition syntax a lot. (a:b foo) is easier to type than (a (b foo)), and the benefits scale linearly; compare (a:b:c:d foo) with (a (b (c (d foo)))), and (baz a:b:c:d) with (baz (fn args (a (b (c (apply d args)))))).
I fail to see the benefits of the function application syntax. Typing a.b is hardly any easier to type than (a b), and is also harder to understand instantly upon reading. As you add more arguments, the bad gets worse and the good doesn't get better. The gains in brevity and typing speed in writing a.b.c.d rather than (a b c d) are no better than those of writing a.b rather than (a b). However, once you start using the syntax for more than one argument, you have to remember that a.b.c.d means (a b c d), rather than (((a b) c) d) or (a (b (c d))). It gets worse when you try to mix them, as in a:b.c, a.b:c, or a:b.c:d (what would this last one even mean?).
Some proposals:
Drop the a.b syntax altogether
Do not allow mixing of . and :
Allow only one . per thing
At the very least, drop a!b and let us just use a.'b; it's easier to understand and no harder to type.
I am not comfortable with disallowing anything, partly due to bad experiences with languages that do so. The other syntax at least makes sense (things like [ _ ], :, and the usual Lisp stuff like ' ` , ,@). I don't see the point of a.b, why not drop it entirely?
I agree- using dots/exclamations in multiparameter functions is definitely pretty scuzzy, so it makes sense to use this semantic space for something else, too...
The reader (I would argue) should always make the assumption that the dot/excl implies single-parameter functions. This would be particularly nice in nested tables... Imagine we had a table of tables of city populations:
I like the idea of the alternatives syntax ! , . , : and ~ ; so I vote up for it.
What I find annoying or confusing is the way they are currently implemented.
I think these operators should be used with literals and first-class objects too, instead of them being only tied to names/symbol merely , the productivity and the usefulness will greatly increase with this change , and it is something probably needed for these operators to survive in the long term.
