[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ruby-talk
Subject:    Re: ANN: Free-form-operators patch
From:       Nikolai Weibull <ruby-talk () pcppopper ! org>
Date:       2004-10-14 11:11:48
Message-ID: 20041014111137.GB9328 () puritan ! pcp ! ath ! cx
[Download RAW message or body]

* Markus <markus@reality.com> [Oct 14, 2004 12:41]:
> > > * This patch makes difficult to add new operators in the language
> > > in the future.  For example, I might feel like to add '->' behave
> > > as lambda as in Perl6.

OK, say that we have this and that it is implemented as something like

alias -> proc

and that we do

def proc
  puts "boom!  proc not available any more!"
end

then

p = -> { puts "lambda-the-ultimate!" }
p.call
lambda-the-ultimate!
q = proc { puts "lambda-the-ultimate!" }
boom!  proc not available any more!
q.call
NoMethodError: undefined method `call' for nil:NilClass

so, as it's easily enough to override the meaning of 'proc', why should
'->' be any different?  Sure, the one big problem is that all methods
have the same precedence and that you can't override it in any way.  If
you would redefine built-in operators, you wouldn't be able to change
their precedence either and it would mess with the whole "all
user-defined operators have the same precedence rule", _if_ there is
such a rule.  So perhaps not all user-defined operators should have the
same precedence.  Either don't add this rule, but keep all new operators
(defined by the user) on a separate level, or allow the user to set the
precedence of operators.  Again, complications arise in the parsing when
things change precedence, but that's another problem.

> > One way to handle that (changing the patch a bit) is to require all
> > user defined operators to be of the form \|.*\| e.g., |+|, or |-|.
> > That would allow all user defined operators to be easily
> > distinguished from the built-ins.  This would allow any desired
> > builtins to be added later, and also make the user defined operators
> > readily recognizable.

> That should be a trivial patch to the patch, if that seems to increase
> the net happiness of the world.  If others speak in favor of the idea
> I'll work it up (*smile* or you are of course free to try your hand at
> it if you prefer).

Yes, but it detracts from the whole point of adding the capabilities of
this patch.   The point isn't to make user-defined operators different
from built-in ones, the point is to make them indistinguishable from
them - to allow us, as programmers, to work in the same namespace as
matz or any of the language designers.  This worries some people, but
I personally don't see an good reason for worry, if done correctly (i.e.
not introducing bugs or breakage).  Remember, Ruby allows you to add and
redefine methods in base classes, so if you want to wreak havoc, the
tools are readily available even without user-defined operators.

Sure, I can see the problem of adding new operators to the core language
contra user-defined ones, yet this can be handled in a similar manner to
that of how any incompatibilities between lanugage revisions seem to be
handled - major versions.   So in Ruby 2.0 there will be a set of new
operators, perhaps '->' for lambda, among other things such as new
methods in new base classes.  Then, the user is free to alter them and
add new operators, methods and classes as they see fit.  Once enough
momentum is gathered, Ruby 3.0 is released with a new set of new
operators, and so on and so on.  Sure, you might not want to go down the
road of "no backwards compatibility", but I believe I read somewhere
that Ruby 2.0 won't be backwards compatible either way,
	nikolai

--
::: name: Nikolai Weibull    :: aliases: pcp / lone-star / aka :::
::: born: Chicago, IL USA    :: loc atm: Gothenburg, Sweden    :::
::: page: www.pcppopper.org  :: fun atm: gf,lps,ruby,lisp,war3 :::
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}

[prev in list] [next in list] [prev in thread] [next in thread]