ANN: Free-form-operators patch

[Brian Candler]

(C) is illegal (but I'm not sure why)
! ~~1 is legal, but !~~1 gives strange results
try: ruby -e '!~~1' and see for yourself.

!~ is a binary operator; "a !~ b" expands to "not (a ~= b)", in the same way
that "a != b" expands to "not (a == b)"

I can't see any useful way to use the construct
a !~ (~b)
with the standard classes though. e.g. ~/bar/ matches /bar/ against $_, but
returns an integer or nil.

Regards,

Brian.

 

[Nikolai Weibull]

the problem I can see is: +,*,- have a ,more or less obvious semantic.

Yet "a" + "b" != "b" + "a".

The problem is: given that -> is not a standard operator, what could
happen if Angelina and Joe Automator implement themselve it for
different things?

That's basically saying that since the method implies? isn't a standard
method, what could happen if Angelina and Joe Automator implement it for
different things.

Maybe we could be happy if standard operators such as
+= or != could be overriden, and everything could become prefix.

+= is given by +, so that's no problem.
nikolai

 

[Nikolai Weibull]

Ah, but that would be great! (And many people are converging on
this very ability.) Not perhaps to write Pascal in ruby (though who
knows?), but I have seen SQL, Postscript, and Forth (for a control
system) integrated with ruby. Plus little "built to suit languages"
that were invented on the spot. In every case, it was The Right Thing
To Do (tm) and made what would otherwise have been a difficult problem
much easier to write, to understand, and to maintain.

Precisely. This is great for domain specific languages,
nikolai

 

[David A. Black]

Hi --

I stand by the abstraction: A sufficiently open system can be turned against
itself to undermine that openness.

There are millions of ways to concretize that abstraction, but most of those
are otherwise unrelated to each other, and they range from the momentous to
the inconsequential. I have no reason and no desire to compare you to a terrorist
or any other form of criminal.

If you don't believe there is such a thing as "too much flexibility," then we
will have to agree to disagree.

Just so Hal doesn't feel all alone, I'll put in a note of skepticism
I'm not eager for Ruby to have, in essence, no fixed syntax. I
think Ruby's strength lies largely in its specificity as a language --
a language that is good at domain-specific things, but still a
particular language -- and if it were turned into a kind of
proto-language, I would feel a sense of loss. Also, I don't want to
have to learn new syntactic rules every time I want to read a program
or use a library.

I know the argument gets made a lot that it can't hurt to have this
feature, that feature, etc., because no one has to use them. I think
that misses the point, though. It's like saying: a flute should have
strings like a violin, in case someone wants it to be a violin. What
you end up with, eventually, is not a musical instrument but a kind of
buffet of characteristics, adding up to nothing. I consider Ruby not
only an instrument, but a work of art, like a flute or violin.

The idea of something being treated as either a flute or a violin
sounds like duck typing What I'm saying, in those terms, is that
I don't consider Ruby itself to be a Ruby object. It's
interesting.... I've thought for a long time that the flexibility and
dynamism of Ruby objects sometimes rubs off on people's views of the
language itself, so that the perception, expectation, or desire is for
Ruby itself to be untyped, open, malleable, and so forth. (Or is that
'mallardeable'? I tend to think of Ruby, instead, as a quite
stable and distinctive thing whose stability supports the dynamism of
the objects.

But at that level it's fine to agree to disagree; there is of course
nothing whatsoever wrong with experimentation. I guess my more
concrete fear -- and I tend to feel this way about all interpreter
patches -- is that people will start releasing programs that depend on
the patch. At that point, it would be better to do an outright fork
of Ruby. But hopefully that won't be an issue. Mainly I just tend to
agree with Hal that this particular change affects the whole profile
and identity of the language.


David

 

[Steven Jenkins]

Just so Hal doesn't feel all alone, I'll put in a note of skepticism
I'm not eager for Ruby to have, in essence, no fixed syntax. I
think Ruby's strength lies largely in its specificity as a language --
a language that is good at domain-specific things, but still a
particular language -- and if it were turned into a kind of
proto-language, I would feel a sense of loss. Also, I don't want to
have to learn new syntactic rules every time I want to read a program
or use a library.

I agree with Hal and David. Part of what appeals to me about Ruby (or
any other language) is identity or integrity--in essence, having a Ruby Way.

I don't complain about it, but I find the substantial volume of traffic
on ruby-talk comparing Ruby to this or that language, or discussing how
to make Ruby more like this or that, tiresome. I read ruby-talk to
become more expressive and powerful in (this) Ruby, and I really don't
care how it stacks up in a Consumer Reports-style feature comparison.

I'm especially wary of extensions to syntax. I don't mind looking up
semantics, but I want to handle syntax without help.

Steve

 

[Markus]

the problem I can see is: +,*,- have a ,more or less obvious semantic.
You can expect them to be implemented to be similar things in diffenret
domains.

The problem is: given that -> is not a standard operator, what could
happen if Angelina and Joe Automator implement themselve it for
different things?

I mean, one could intend it as a function definition operator, while
the other could use it to indicate movements of an hunter in the usual
wumpus labyrinth. then their two library would be completely incompatible.

By exactly the same argument, we could claim that users should not
be able to define their own identifiers. What if I think 'web' has
something to do with fishing, while you think it has something to do
with printing. And who knows, maybe somebody else has a third
definition. Think of the chaos.

Remember, operators aren't defined in a vacuum, nor are they
global. They are defined as messages send to objects, just like
methods.

-- Markus

 

[Nikolai Weibull]

Yes, that was part of my inspiration for this. In theory it is
simple; in practice (especially since I don't know C) the devil has been
in the details. Specifically, Eiffel doesn't execute
definitions/declarations, while ruby does. This makes life more
interesting.

Take a look at Haskell. It has user-defined operators with adjustable
precedence,
nikolai

 

[trans. (T. Onoma)]

On Saturday 09 October 2004 12:10 pm, Steven Jenkins wrote:
| I agree with Hal and David. Part of what appeals to me about Ruby (or
| any other language) is identity or integrity--in essence, having a Ruby
| Way.
|
| I don't complain about it, but I find the substantial volume of traffic
| on ruby-talk comparing Ruby to this or that language, or discussing how
| to make Ruby more like this or that, tiresome. I read ruby-talk to
| become more expressive and powerful in (this) Ruby, and I really don't
| care how it stacks up in a Consumer Reports-style feature comparison.
|
| I'm especially wary of extensions to syntax. I don't mind looking up
| semantics, but I want to handle syntax without help.

Well, such things are important. Good ideas rarely (if ever) just pop out of
thin air. Netwon himself stood on shoulders. So its important that people
talk about such things. It helps people learn why Ruby is the way it is and
it helps Ruby improve, and some of us just plain enjoy it!

Yet, I know some people, like yourself, feel this way about ruby-talk. So I
have tried multiple times to get a separate mailing list invigorated for this
very purpose. But none of the major players will back it, and as long as that
is the case it just won't fly, and these discussions _will_ continue here. I
can only assume that the Ruby community is just to small to support the
division of lists.

So Ruby-talk remains the avenue for these explorations, which indeed tend to
be long and detailed by their very nature.

Sorry,
T.

 

[Markus]

Just so Hal doesn't feel all alone, I'll put in a note of skepticism
I'm not eager for Ruby to have, in essence, no fixed syntax. I
think Ruby's strength lies largely in its specificity as a language --
a language that is good at domain-specific things, but still a
particular language -- and if it were turned into a kind of
proto-language, I would feel a sense of loss. Also, I don't want to
have to learn new syntactic rules every time I want to read a program
or use a library.

I think you are grossly misunderstanding what the patch does. It
does not make ruby's syntax more complicated or more variable; in fact,
part of the goal (see the thread about a month back on Hash,
Association, & the => construct) is to make the syntax simpler and more
consistent.

At present, if you see a concatenation of operator-characters you
have to wonder: is that an operator? Is that a build in part of the
syntax? Is it an error? Or maybe it's two or more operators run
together...I wonder where the breaks should be.

If this change were made standard (and it is no where near ready
for that at this moment) you would simply say "ah, that's an operator"
in the same way that you can now say "ah, that's a method call" or "ah,
that's an integer."

I know the argument gets made a lot that it can't hurt to have this
feature, that feature, etc., because no one has to use them. I think
that misses the point, though. It's like saying: a flute should have
strings like a violin, in case someone wants it to be a violin. What
you end up with, eventually, is not a musical instrument but a kind of
buffet of characteristics, adding up to nothing. I consider Ruby not
only an instrument, but a work of art, like a flute or violin.

Ultimately, this patch would involve simplifying the parser,
removing parts rather than adding them.

The idea of something being treated as either a flute or a violin
sounds like duck typing What I'm saying, in those terms, is that
I don't consider Ruby itself to be a Ruby object. It's
interesting.... I've thought for a long time that the flexibility and
dynamism of Ruby objects sometimes rubs off on people's views of the
language itself, so that the perception, expectation, or desire is for
Ruby itself to be untyped, open, malleable, and so forth. (Or is that
'mallardeable'? I tend to think of Ruby, instead, as a quite
stable and distinctive thing whose stability supports the dynamism of
the objects.

"mallardeable: able to be duck typed"! I like that!

But at that level it's fine to agree to disagree; there is of course
nothing whatsoever wrong with experimentation. I guess my more
concrete fear -- and I tend to feel this way about all interpreter
patches -- is that people will start releasing programs that depend on
the patch. At that point, it would be better to do an outright fork
of Ruby. But hopefully that won't be an issue. Mainly I just tend to
agree with Hal that this particular change affects the whole profile
and identity of the language.

1) I have no intention of forking, 2) I have no intention of
releasing programs that depend on this (though I may show samples of how
it could be used). 3) You guys are way overestimating the significance
and impact of this patch. All I'm ultimately doing is cleaning up some
special cases in the syntax, making it so that things work consistently.

I'd rather see potential language ideas floated as patches so that
people can try them and see if they like them before they get stuck with
them, but that's just the form my change adversity takes.

-- Markus

 

[Steven Jenkins]

Yet, I know some people, like yourself, feel this way about ruby-talk. So I
have tried multiple times to get a separate mailing list invigorated for this
very purpose. But none of the major players will back it, and as long as that
is the case it just won't fly, and these discussions _will_ continue here. I
can only assume that the Ruby community is just to small to support the
division of lists.

For the record, I'm not saying such discussions are out of place, nor
suggesting they be taken elsewhere. I've been reading Usenet and its
descendants since 1984, and I know it's a lot easier to ignore stuff you
don't like (or don't approve of) than to add a layer of meta-argument
about whether you ought to be having the argument.

I'm just trying to encourage more discussion of hacking *in* Ruby, as
opposed to hacking *on* Ruby.

Steve

 

[trans. (T. Onoma)]

On Saturday 09 October 2004 02:24 pm, Steven Jenkins wrote:
| I'm just trying to encourage more discussion of hacking *in* Ruby, as
| opposed to hacking *on* Ruby.

I see. I think part of the high "on" volume is b/c 2.0 is in the works.

As for me a lot of my Ruby work is library stuff, so even my "ins" tend to be
"onish" too

T.

 

[Hal Fulton]

For the record, I'm not saying such discussions are out of place, nor
suggesting they be taken elsewhere. I've been reading Usenet and its
descendants since 1984, and I know it's a lot easier to ignore stuff you
don't like (or don't approve of) than to add a layer of meta-argument
about whether you ought to be having the argument.

I concur. As an aside, I'm additionally frustrated by the inverted nature
of the competence-vs-verbosity graph. Not referring to any specific
individuals, I have noted a tendency over the years for the more knowledgeable
people to keep silent on such matters, while the dilettantes and nubies and
script kiddies wax eloquent on how Ruby should be changed. (Again, I am
speaking of the past five years, not the past five days.) Of course, there are
counter-examples.

I'm just trying to encourage more discussion of hacking *in* Ruby, as
opposed to hacking *on* Ruby.

I like that, too. Again it seems upside-down to me: I'd like 80% "in" and
20% "on"; but often it seems the other way around.

But my approach, for what little it's worth, is the same as in other areas
of life. When there's too much A and not enough B, and I can't or shouldn't
decrease the amount of A, then I can at least increase the amount of B.

Among other assumptions, that's assuming we don't go beyond some reasonable
upper limit for A+B.

So my $0.02 is this:

- I like the quizzes, as they typically involve using Ruby as-is
- I like nuby questions (esp. from nubies who haven't learned enough Ruby
to want to change it, or those who have finally learned enough that they
don't want to change it as much as they used to)
- I like the "How do I do this?" questions. There is a book based on that
paradigm, you know.
- I like the stuff that says: Hey, look what I did in Ruby without changing
Ruby at all!
- I like to see project announcements and new releases. Yes, even alpha
versions. Yes, even in languages I can't read.
- I like to hear Ruby success stories, where it's being used in the real
world, how it solved a problem in ten minutes instead of ten hours, how
it made someone's jaw drop.
- I like seeing tutorials made and articles written, whether electron or
dead tree.
- I like seeing explanations of things that I understand marginally or not
at all, like inversion of control in Ruby.
- There are many other things I'm forgetting here. Ruby can, should, and will
change, and that stuff needs to be discussed. But there is so much good stuff
to talk about besides *changing* Ruby!

One man's signal is another man's noise. If you can't filter out all the noise,
boost the signal. Just my opinion.


Hal

 

[Eivind Eklund]

Just so Hal doesn't feel all alone, I'll put in a note of skepticism
I'm not eager for Ruby to have, in essence, no fixed syntax. I
think Ruby's strength lies largely in its specificity as a language --
a language that is good at domain-specific things, but still a
particular language -- and if it were turned into a kind of
proto-language, I would feel a sense of loss. Also, I don't want to
have to learn new syntactic rules every time I want to read a program
or use a library.

Count me on the side of the sceptics. I have the precise worry that
David express here.

There is one limitation on the concept that I think might mitigate my
fears (I've not quite decided yet): Restrict it to work for very
specific domain languages.

In other words, make it so you have to do an
operator_eval(my_operator_set) {
... code with weird operators here ...
}
to make it work.

However, I'm not certain how the utility of extra operators with that
restriction would turn out.

Eivind.

 

[Charles Hixson]

Markus ha scritto:



the problem I can see is: +,*,- have a ,more or less obvious semantic.
You can expect them to be implemented to be similar things in
diffenret domains.
The problem is: given that -> is not a standard operator, what could
happen if Angelina and Joe Automator implement themselve it for
different things?

I mean, one could intend it as a function definition operator, while
the other could use it to indicate movements of an hunter in the usual
wumpus labyrinth. then their two library would be completely
incompatible.

Maybe we could be happy if standard operators such as
+= or != could be overriden, and everything could become prefix.
I guess this could be enough power.

This is a real problem. Mutual dialects can diverge sufficiently to be
mutually unintelligible. BUT that won't happen to any significant
degree unless each one is sufficiently useful in some problem domain
area. It's already possible to write unintelligible code in Ruby.
(Certainly to write code that *I* can't understand.) This doesn't mean
that I feel that certain features which some people find very powerful
and valuable should be removed from the language. It means that I
haven't yet bothered to learn how to use that part of the language.

Similarly, if user defineable operators become a part of the language,
nobody will be required to use them. And presumably people usually
WON'T use them. They'll only be (commonly) used where their use
improves the code. There will, of course, be experiments by J. Random
Hacker, but so what? If it doesn't do anything important, it will be
forgotten. If it does, then those who find it important will learn how
to use that feature. And if someone wants to use two mutually
incompatible dialects, then they will need to come up with a way to
harmonize them. Exactly as is done with libraries of functions.

Every objection that I've heard to user defined operators would apply
with equal vigor to user defined functions, if the language didn't
already include them.

OTOH, if the argument is made that these techniques should be
implemented as libraries that one needs to require... that has a lot of
validity. They should only be included in the core language if that
would significantly improve the core itself. The only other argument
for including them in the core is if they can't be done any other way,
and in that case it would probably be better for there to be an
experimental fork of the code that included them. (Undesireable, but
better that including experimental features in the core.)

It shouldn't, and doesn't have to be, an all or nothing kind of thing.
It should be a"Use however much you want, and don't complain bitterly if
you cut your finger on the bleeding edge. You were warned." kind of
thing. Naturally exotic features will have less support. If they were
in common use, they wouldn't be exotic. And there should be a path into
learning Ruby that's no steeper than the current path. Currently one
can learn enough to start being productive in a couple of hours. And
one can study for years, and still encounter new things. This is an
important characteristic!

 

[Markus]

For the record, I'm not saying such discussions are out of place, nor
suggesting they be taken elsewhere. I've been reading Usenet and its
descendants since 1984, and I know it's a lot easier to ignore stuff you
don't like (or don't approve of) than to add a layer of meta-argument
about whether you ought to be having the argument.

I'm just trying to encourage more discussion of hacking *in* Ruby, as
opposed to hacking *on* Ruby.

*smile* I tried to join ruby-dev, first, but the list appears to
be closed. I was assured by several people that this was the place for
such discussions, and that attempts to start a separate list for people
uninterested in such issues had met with little or no success. Maybe we
could have an honor system, e.g. agree to put "(dev)" in the subject of
such threads, so that those who don't like them can filter them?

-- Markus

 

[gabriele renzi]

Nikolai Weibull ha scritto:

That's basically saying that since the method implies? isn't a standard
method, what could happen if Angelina and Joe Automator implement it for
different things.

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, + )

+= is given by +, so that's no problem.
nikolai

actually, I'd like to override += (just think of Array#+= done via in
place addition or with sum and reassign), just to say

 

[Nikolai Weibull]

actually, I'd like to override += (just think of Array#+= done via in
place addition or with sum and reassign), just to say

Well, there you go. Your whole reasoning just went down the drain. If
this would be allowed, how would anyone keep track of how += for
arrays differs from += for, say, integers. It's more confusing to alter
the meaning of some "well understood" operator than to add new ones with
new semantics,
nikolai

 

[Markus]

I've just posted ver 0.3 of the acclaimed and controversial free-form
operator patch. It fixes all the bugs reported so far (including
supporting the "proc {|x,*|x}" monstrosity).

The web page is as bland/ugly as ever, and still at:

http://www.reality.com/roberts/markus/software/ruby/free_form_operators/

Thank's everyone for all the support, including those of you that have
supported by challenging my assumptions and/or sanity (or should I saw
"assumptions &&/|| sanity" in undertaking this in the first place.

-- Markus

 

[Brian Candler]

Similarly, if user defineable operators become a part of the language,
nobody will be required to use them.

I'll just chime in once, to say I support Hal's view, which he expressed
very eloquently.

I realise that I am treading on somewhat dangerous water here, in that I
have been involved in other threads on things like method call versus block
call semantics. I'm not saying the language cannot be improved, and I'm
equally sure a lot of user input and suggestions over the last ten or eleven
years have helped make 1.8.x as good as it is.

However, ISTM that what's being described here is a substantially different
language to Ruby. Sure, there is some intellectual satisfaction in the
exercise; you can continue down this route making the language somehow more
'flexible' or 'pure' or 'minimalist' or whatever - like removing instance
variables altogether and replacing them with closures. It would be
interesting to see what the smallest subset of Ruby is that can bootstrap up
to the full feature set. Maybe it would end up looking like Lisp (or Eiffel,
Smalltalk, Haskell or many other languages mentioned here as comparatives
before which I don't know or use)

However, Matz has been doing the language-design exercise for more than 10
years, and most of us are very happy with what he's produced. This idea has
probably been floated and considered in the past. If it's not in the
language, probably it doesn't fit his overall world view of what the
language should look like. Draw your own conclusions from his silence on
this thread, and on the likelihood of this feature ever making it into the
core.

If it doesn't do anything important, it will be
forgotten.

If it doesn't do anything important, then it shouldn't have been added in
the first place. ISTM that user-defined operators are nothing more than
syntactic sugar, which Ruby has plenty of already, and add nothing that
can't be done with a handful more keystrokes. I'd rather see discussion on
language semantics, which can make life substantially easier or harder when
programming.

If it does, then those who find it important will learn how
to use that feature. And if someone wants to use two mutually
incompatible dialects, then they will need to come up with a way to
harmonize them.

Or just use a different language in the first place, which is more suitable
to their particular problem domain.

Ruby matches the problem domains that I deal with very nicely at the moment.

It shouldn't, and doesn't have to be, an all or nothing kind of thing.
It should be a"Use however much you want, and don't complain bitterly if
you cut your finger on the bleeding edge. You were warned." kind of
thing. Naturally exotic features will have less support.

The original comment I wrote at this point was:

"Personally I see Ruby as a stable platform to do real work on, not an
experimental platform for wannabe language designers."

But then I realised it sounded bitchy as hell. No offence is intended to
anyone, so please substitute a less inflammatory statement of your choosing.

Regards,

Brian.

 

[gabriele renzi]

Nikolai Weibull ha scritto:

Well, there you go. Your whole reasoning just went down the drain. If
this would be allowed, how would anyone keep track of how += for
arrays differs from += for, say, integers.

Sorry but you misunderstood my point completely.
I don't want to keep track, I expect people to do the right thing just
like they do now (i.e. not redefining Fixnum#<=> to be the opposite of
Bignum#<=>).

I expect that if people would override += they would do this sanely.

It's more confusing to alter
the meaning of some "well understood" operator than to add new ones with
new semantics,

I am not against the concept of new operators, I said I like the idea.
And I do not expect people to be idiot, where they would override
important operators they would probably do this for some good reason
(i.e. Criteria-like things would benefit from overriding !=).

What I am afraid of is the interaction beetween different users's
language extensions, in a space where name collision is more easy than
in the method's one.

But there you go, we both exposed our reason let matz decide