Alternative keyword chaining syntax

[GoogleCodeExporter]

The problem:
------------

Currently when writing and editing code, to call a keyword on something you
almost always have to go back to the beginning, add an opening paren, and
another at the end, and then add the keyword arg call.

So when you're writing code from the start, you can either think of how
many keyword calls you'll be doing and write that many open-parens and
*then* start writing, or you can just get going and fumble back and forth
adding them.

So, say you have some expression, the initial being:

    1 upTo: limit

and you want to call #collect: on it, you must turn it into:

    (1 upTo: limit) collect: ["..."]

and if you want to call #gather: on that, you must do:

    ((1 upTo: limit) collect: ["..."]) gather: ["..."].

Whether you're editing existing code or especially writing it as you go
along, this is quite disruptive, especially as opposed to unary method
calls, which can be chained elegantly with zero disruption or line noise.

The proposal:
-------------

An alternative keyword chaining syntax; still using parentheses, but in a
less disruptive manner to writing code.

The above examples progress as follows:

    1 upTo: limit
    1 (upTo: limit) (collect: ["..."])
    1 (upTo: limit) (collect: ["..."]) (gather: ["..."])

Notice how while there is the same amount of parens, they do not build up
in any one spot; they are added as you need them. There is, however, the
issue that for the initial keyword call you still have to go back and add
the opening `(', but this is much less jarring, as when initially writing
the code the question now just "am I going to call more than this
keyword?", rather than "how many keywords will I be calling here?".

Bonus:
------

An additional syntax building on this was mentioned as an alternative to
`>> cascades. This is just adding more expressions inside the parentheses.

For example:

    a `>> [b: c. d: e.].

would simply become:

    a (b: c. d: e.)

This adds a different way of reasoning about the original proposal which
seems to fit in pretty comfortably with the general idea, if you think of
it like this:

    A ( B ) ( C ) ( D )
       A+1   A+2   A+3 

With A being the origin, B contains whatever expressions to call on A, this
"group" denoted as A+1, or one level of abstraction from A; its value is
the new target for C, containing expressions that run on level A+2, and so on.

Original issue reported on code.google.com by suraci.a...@gmail.com on 7 Feb 2010 at 10:30

[GoogleCodeExporter]

I am in agreement about the usefulness and lack of conflict with existing 
syntax, but 
still need to make a concrete scheme to implement it.

Original comment by BrianTRice on 16 Feb 2010 at 5:10

• Changed state: Accepted

[GoogleCodeExporter]

Original comment by BrianTRice on 16 Feb 2010 at 5:10

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

This is now implemented using Syntax Partial, so that:

A #(B) #(C) #(D) ==> (((A B) C) D)

for any given message pattern. Underscore can also be used if the fill-in area 
should not be the left-most implicit place.

Original comment by BrianTRice on 18 Nov 2010 at 12:17

• Changed state: Fixed