ANN: Free-form-operators patch

[Yukihiro Matsumoto]

Hi,

In message "Re: ANN: Free-form-operators patch"

|I haven't settled my opinion about this patch. Surely this is a
|interesting change, but has some concerns.

One thing to add:

* 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.

matz.

 

[Gavin Sinclair]

The selector namespace might help isolate influence from this change
within certain static scope, but I still do not have a good idea to
implement it effectively, or even how it should behave.

I'm very keen on the selector namespace feature, but share your
head-scratching as to how it could be implemented.

Gavin

 

[Robert Klemme]

Hi,

In message "Re: ANN: Free-form-operators patch"

| Matz is a nice, reasonable, and very intelligent guy. If (and the
|jury is still out) I can make this work and suggested it for actuall
|use, but do so in a way that is incompatible with the big picture, I'm
|sure he'll point it out to me himself.

I'm a nice and reasonable guy but not sure being intelligent.

Don't worry: the rest of your posing ascertained us that you are in fact.

I haven't settled my opinion about this patch. Surely this is a
interesting change, but has some concerns.

* I am against for user defined operator precedence. It's just
wrong. So forget about that idea. All user defined operators
should have same precedence, even if they are allowed.

+2 (Also, since precedence is typically implemented in the parser I can
imagine that user defined precedence makes for awful changes in the parser
which has considerable complexity already AFAIK.)

* I'm little bit afraid of the potential confusion (or obfuscation)
caused by this change, especially in combination with open classes.
I don't fully trust programmers. They need freedom. But too much
freedom might hinder usefulness of a language.

True. I'm not sure whether I really miss user definable operators in
Ruby. I think, rather not.

I didn't follow the whole thread, so this might have been discussed
already: what about a clean way of integrating other (sub) languages? I
remember the topic as such has been discussed before, but I'm not sure
whether someone already related it to this thread. If such a feature
existed, the need for user definable operators might disappear.

Kind regards

robert

 

[Markus]

On Mon, 2004-10-11 at 02:19, Robert Klemme wrote:
+2 (Also, since precedence is typically implemented in the parser I can
imagine that user defined precedence makes for awful changes in the parser
which has considerable complexity already AFAIK.)

The parser part (at least in isolation) isn't too bad. Instead of
one operator token (tGENERIC_OP) you have a set of them (tOP1..tOP9 say)
which have a range of precedences by varying semantics. The user then
gets to choose which token to use for each op. Since these could also
be used for many/most of the built-in operators, it might actually
simplify the parser.

The complication come when you start to work out the "scope" of a
declared operator precedence; if it is very global the chance of
conflict (I want it to be 7 in my library, you want it to be 3 in yours,
and poor Joe requires both libraries) goes way up. But if it is not as
global as global can be, there are other problems. The best I have been
able to do is come up with a compromise that clearly has both problems.

-- Markus

 

[Martin DeMello]

sure, but a method has a name wich explains what it does, an operator
does not. I understand that this thinking brings to "let's remove all
operators!" mood, but actually having just some is ok, specially if they
have a widely used meaning (say, + )

Actually, when you're trying to implement domain-specific languages atop
ruby, the operators often have a well-defined meaning; it just comes
from the domain rather than the larger body of 'programming languages'.
For instance, it might be nice to define a financial maths class with
$12 creating a money amount literal (what, no prefix operators? ). It
also gives the community a chance to experiment with symbols for common
idioms (for instance, a ||+ b for elementwise array addition) - if the
symbols aren't intuitive they'll just die a natural death.

martin

 

[Robert Klemme]

Actually, when you're trying to implement domain-specific languages atop
ruby, the operators often have a well-defined meaning; it just comes
from the domain rather than the larger body of 'programming languages'.
For instance, it might be nice to define a financial maths class with
$12 creating a money amount literal (what, no prefix operators? ). It
also gives the community a chance to experiment with symbols for common
idioms (for instance, a ||+ b for elementwise array addition) - if the
symbols aren't intuitive they'll just die a natural death.

But isn't a sub language integration feature the more appropriate approach
in this case?

Kind regards

robert

 

[Markus]

In message "Re: ANN: Free-form-operators patch"

|I haven't settled my opinion about this patch. Surely this is a
|interesting change, but has some concerns.

*smile* agreed on both counts.

As I've stated several times, I'm not arguing for this as a change
at this time--it is an exploration, and an unproven one at that. It is
not (IMHO) RCR-ready yet.

The main value initial--letting people extend things to suit
themselves rather than lobbying for changes in the core classes might be
obtained even if it were never "accepted"; anyone who wanted to argue
for a change could prototype it with this patch as a step in
demonstrating how their idea would work (I'm thinking of the
Associations class idea, and some of the people who are playing with
ranges). Prototyping in this way might help people find the weaknesses
in their ideas (I know it does for me).

* 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.

I wasn't familiar with the '->' in perl6, but was guessing it was
something like the trick in scheme. When I went to look it up, I
noticed that perl6 also has user defined operators of arbitrary
precedence--or will, if/when it finally comes out ("operator
subroutines" in http://dev.perl.org/perl6/apocalypse/A06.html). I'm not
thrilled with Larry's design at first glance, but that just may be
overspill from the fact that I find perl cluttered in the first place.
But still I found it amusing.

I don't think the patch would make it any harder to add operators
in the future--any more than user defined methods make it harder to add
methods. In a way, it might make it easier, since they could be written
in ruby.

What it would make harder is "pseudo-operators" such as "<<" (in
the class & here-doc contexts) which are more reserved words that
operators; those could get even messier to add than they already are.

-- Markus

 

[Martin DeMello]

But isn't a sub language integration feature the more appropriate approach
in this case?

Not sure what you mean by sub language integration; if you're talking
about stuff like Inline::Foo or embedded interpreters, no I prefer the
DSL approach. It lets you coexist with and drop down to ruby a lot more
easily.

martin

 

[Markus]

Actually, when you're trying to implement domain-specific languages atop

But isn't a sub language integration feature the more appropriate approach
in this case?

Perhaps. But I had no idea how to implement that in a few days.

-- Markus

P.S. And, now that I think on it for a moment, it opens a whole new
question: where do you draw the line. SQL would be an embedded
sub-language. So would regular expressions. What about Hashes?
Strings? I could see arguments for both...but then where do you stop,
and why?

Definitely not something I could work up a quick patch for.

 

[trans. (T. Onoma)]

On Monday 11 October 2004 12:43 am, Yukihiro Matsumoto wrote:
| I KNOW thinking about enhancing the language is FUN. But let me
| propose moving RCR related things to ruby-core for plain users' sake.

That's reasonable in my view. Up 'til now core has been slated for reporting
obvious bugs (often compiling errors) and patches --very very low volume. I
fear some may wish to keep it that way, as was my experience once before.
What do others think?

T.

 

[ts]

t> That's reasonable in my view. Up 'til now core has been slated for reporting
t> obvious bugs (often compiling errors) and patches --very very low volume.

Personnaly I think that it's a good thing to have a low volume in
ruby-core

For obvious bugs, you can still reply to [ruby-core:03483]


Guy Decoux

 

[gabriele renzi]

Gavin Sinclair ha scritto:

I'm very keen on the selector namespace feature, but share your
head-scratching as to how it could be implemented.

some smalltalk have namespaces. No SmallTalker here that could share his
knowledge?

 

[Austin Ziegler]

At it's core, all this patch does is remove the asymmetry in how
operator tokens are defined (to include any combination of operator
characters, using a simplified for of the code for identifiers).

Mmmm. By this do you mean that you lose the automatic definition of +=
when you define + ? If this is the case, I think that it's entirely
too dramatic. I depend on this behaviour in a few things.

-austin

 

[Markus]

Mmmm. By this do you mean that you lose the automatic definition of +=
when you define + ? If this is the case, I think that it's entirely
too dramatic. I depend on this behaviour in a few things.

Not at all.

First off, + is already a user definable operator, so it's
unaffected.

But second, even supposing that neither += nor + was built in,
changing the definition of + would not affect += any more than changing
the definition of MyClass#zoo would be expected to affect the definition
of MyClass#zookeeper.

The asymmetry referred to in the comment you quoted was between
identifiers (which can be any non-reserved sequence of identifier
characters) and operators (which can not, without the patch, be any
non-reserved combination of operator characters).

-- Markus

 

[Charles Hixson]

Hi,

In message "Re: ANN: Free-form-operators patch"

|I haven't settled my opinion about this patch. Surely this is a
|interesting change, but has some concerns.

One thing to add:

* 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.

matz.

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.

 

[Markus]

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).

-- Markus

P.S. I am taking the "." in your regexp to mean "any operator character"
and not "any character" as the later would lead to untold complications.

 

[Nikolai Weibull]

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.

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

 

[ts]

N> matz or any of the language designers. This worries some people, but
N> I personally don't see an good reason for worry, if done correctly (i.e.
N> not introducing bugs or breakage). Remember, Ruby allows you to add and
N> redefine methods in base classes, so if you want to wreak havoc, the
N> tools are readily available even without user-defined operators.

Well, for me an operator is defined by
* it's type (unary, binary, tertiary)
* associativity (right, left, non-assoc)
* precedence

If I can't define all of this, it's useless for me. If I can define it, my
user-operator will probably conflict with the same user-operator defined
by someone else.

Like has said matz, this will freeze ruby (matz don't have the possibility
to add new operator).

And sincerely, I don't want that ruby finish like APL with %$@%


Guy Decoux

 

[Nikolai Weibull]

Well, for me an operator is defined by
* it's type (unary, binary, tertiary)

Sure, easy to fix.

* associativity (right, left, non-assoc)

True, this could become and issue.

* precedence
Definitely.

If I can't define all of this, it's useless for me. If I can define
it, my user-operator will probably conflict with the same
user-operator defined by someone else.

I really don't follow this reasoning.

Like has said matz, this will freeze ruby (matz don't have the
possibility to add new operator).

? You mean that matz won't be able to add new operators as they may
have user-defined equivalents? I explained the solution to that issue
in the rest of my mail.

And sincerely, I don't want that ruby finish like APL with %$@%

Have you _actually_ done any _real_ programming in APL, or are you
simply using it as an example without knowing anything about APL, more
than that it has a rather one-line oriented syntax? I don't want APL
either, but that's beside the point. You can't define new operators in
APL and you basically can't extend the language with anything else
either. (At least this was true for the first incarnations of the
language.) Learning APL isn't very different than reading the Java
SDK/API. Furthermore, APL didn't start looking like Algol and then
converge to its current incarnation. It was always meant to be a
concise, mathematical, representation of a program. Did you know that
there actually exists a verbose syntax for APL as well? Anyway, it's
domain is more or less limited to mathematical expressions, which it is
very well suited for. So, until Ruby becomes a purely mathematically
oriented programming language, your worries are unwarranted.
nikolai

 

[David A. Black]

Hi --

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.

Yes, but first of all people tend not to, and a lot of concern and
thought has gone into (and is still going into) the question of how,
and even whether, it's possible to modify base classes in a safe and
'polite' way.

Second, the openness of classes (base or otherwise) does not have any
implications for operators, unless you're assuming a kind of
all-or-nothing, single, monolithic design principle for everything in
Ruby (which, luckily for us, there isn't In other words, by
making classes open, Matz has made classes open, without incurring any
obligation to make an analogous design decision elsewhere in the
language. That also doesn't mean that user-defined operators are a
bad idea. It just means that they're being or not being a good idea
is separate from the matter of the openness of classes.


David