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.