--tKW2IUtsqtDRztdT
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Mar 26, 2011 at 07:21:25PM +0900, Robert Klemme wrote:
> >
> > IDK how well this would work or its potential ramifications, but i
> > think it fits into the 'flavor' of ruby to be able to do such things
> > (i mean, you can define/change damn near *everything else* in the
> > language, why not operators?)
> 
> Because that would completely break parsing.  Whenever an operator 
> definition would be seen the whole source would need reparsing - or at 
> least part of it.  It would be tricky to determine which part.

I'm not so sure about that.  If it were just possible to specify that a
method need not be connected to its object with the "dot", it would give
the appearance of an infix operator for those who really want it, but
would only conform to the standard rules for method calls.  The parser
would just have to maintain a last-object context of one to determine
whether what follows is a method to which the last object responds.

Of course, I'm not sure that would be so great a task to dump on the
interpreter, but I don't think it would necessarily be as dire as you
describe, as long as we're willing to recognize that infix arithmetic,
comparison, and assignment operators are actually methods.

Frankly, I'd be happy without infix operator syntax (with its precedence
rules) at all.  2.plus(3) is conceptually simpler than 2 + 3 in the
context of code; so is something like (+ 2 3), add(2,3,), or sum 2 3.

2.plus 3 looks pretty "infix"y to me anyway, but it's still a method call
with obvious meaning and precedence.

-- 
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]

--tKW2IUtsqtDRztdT
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (FreeBSD)

iEYEARECAAYFAk2OCiUACgkQ9mn/Pj01uKVH7gCeOpJ8CPUu68lJI+0jdBaf4W9v
78oAoKeS7PlUwVpWDREM/7ji/9CdpcTo
By
-----END PGP SIGNATURE-----

--tKW2IUtsqtDRztdT--