RCR 229: Mixf-fix syntax, if-then-else etc. as methods, fewer keywords

This RCR allows users to define methods with mix-fix syntax (post-fix, pre-fix, in-fix). It allows 2.0 keyword arguments. It uses this to replace some special forms (e.g. if-else) with normal method definitions.

Ruby has mostly postfix (x.y), some infix (x[5]=0), and some prefix (not x). It also has special forms for familiarity (if-then-) where Smalltalk has just methods ifTrue:[...]. In addition to these special cases, the user cannot define their own prefix or infix methods.

Allow users to define mix-fix methods including self and keyword arguments

• unless unambiguous, all params in method def must be in parenthesis
• allow method name to be split before, between, and after parameters
• allow keyword params in any position
• self is an optional distinguished parameter indicating position of receiver in method invocation

Examples of method definitions:

1. def at(i)put(v)
2. def at(i, put:)
3. def post (p1:, p2:)...
4. def if (self:, then:)...
5. def if(self)then(&block)
6. def prefix (self:)...
7. def mix (self, post:)...
8. def mix (self) post (y)
9. def [ (index) ] = (value)

Allow corresponding mix-fix invocations, parenthesis required only when otherwise ambiguous. Examples below correspond to method definitions above, and use R as receiver

1. R.at(i) put (5)
2. R.at(i, put: 5)
3. R.post (p1:1, p2:2)
4. if R then: proc
5. if R then {...}
6. prefix R
7. mix R post: y
8. mix R post y
9. R [ 5 ] = 0

• Big change, requires incremental grammar approach to parsing, will likely introduce incompatibilities
• split method names (e.g. in mix-fix mode) and keyword arguments have some overlap.

Two implementations of incremental grammar definition and parsing, both quite doable in Ruby, but I don't know current parser constraints:

• http://research.microsoft.com/Users/ luca/Papers/FSubImp.A4.pdf
• http://www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-121.html

Clases (e.g. in modules) can introduce custom mix-fix syntax. Module 'require' chains have corresponding grammar definition incrementally built up. Ruby's current post-fix and pre-defined operators would be "built-in" by virtue of built-in library modules being required first.