ANN: Free-form-operators patch

[trans. (T. Onoma)]

19:30AM +0900, Charles Hixson wrote:
| > 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.

Know what noise is? Another word for static. Know what static is? Something
that never changes. You know what something that never changes is?

D E A D

Honestly I sick and tired reading emails about how it is bad bad bad to talk
about changes to Ruby.

Anyone remember this?

| At Tue, 1 Apr 2003 13:08:42 +0900,
| Austin Ziegler wrote:
| > Now, rb_iv_set/rb_iv_get aren't visible from the Ruby side
| > (apparently), but they are visible from the C side. Are there good
| > reasons to not allow this, or can we modify it so that iv_get and
| > iv_set (or better names for them) are available as private methods to
| > go along with instance_variables?
|
| Kernel#instance_variable_get and #instance_variable_set are
| added in 1.8.
|
| --
| Nobu Nakada

It's not like matz and the other developers aren't interested and listenting.
If they weren't why would they _ever_ talk to the community about this stuff?
matz is quiet b/c his postion requires that he be very conservative. That
doesn't mean the rest of us shouldn't pursue our dreams. Every once in a
while one of those "gets out of the park", and ends up making Ruby better.

Brian, I'm a bit surprised at this given our conversation on Range class. Hal,
I'm not surprised at all. Seems like you bring this up every time a Ruby
suggestion thread (with which you don't agree with, of course) gets any
significant feedback.

Even so, I'm a nice guy. I feel for you. But you can't say I haven't tried
--I've pushed for a separate mailing list for this stuff for, lord knows, how
long now?

T.

 

[David A. Black]

On Sunday 10 October 2004 05:48 am, Brian Candler wrote:

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

Know what noise is? Another word for static. Know what static is? Something
that never changes. You know what something that never changes is?

D E A D

I know no one who thinks, or has ever suggested, that Ruby should
never change. (I used to muse about a feature freeze, but only a
two-year one I have, however, heard this "no change == dead"
thing thrown at people several times over the years, as a way of
lashing out at them, not because they think Ruby should never change
but either because they do not support a particular change or, perhaps
more often, because they do not have a vision of Ruby as a kind of
syntax soup (i.e., they think there are some ways in which Ruby should
NOT change, and/or some ways in which Ruby should not be changeable
programmatically). I'd be perfectly happy never to hear it again.

[...]

Even so, I'm a nice guy. I feel for you. But you can't say I haven't tried
--I've pushed for a separate mailing list for this stuff for, lord knows, how
long now?

OK... but maybe that means there's no interest in it...?


David

 

[Jamis Buck]

OK... but maybe that means there's no interest in it...?

David, that's a little harsh. Tom has pushed his suby-muse list in a
very non-aggressive way, trying to get interested readers to the list.
(It's a great list, BTW. Low volume due to low membership right now, but
the discussions have included fascinating dissertations on AOP and
prototype-based languages. Great stuff.) People are obviously interested
in discussing changes to the Ruby language itself (witness this thread).

Part of the problem is--people want their ideas _heard_. And because of
suby-muse's low volume, it is not a tempting target for many amateur
language designers. So they post on ruby-talk and a flame-war ensues.

Personally, I'm something of a fence-sitter in the current issue. I like
the operators patch--goodness knows there have been times I've wanted to
override operators in Ruby--but I've always found an acceptible (if not
perfect) workaround. So obviously, Ruby as it is now is "sufficient."

However, I think there is very little need to worry about Ruby becoming
a "syntactic soup" as someone mentioned earlier. First of all, NONE of
us have any real say in what goes into or stays out of Ruby. If matz
likes an idea, he'll uses it. If he doesn't, he won't. Naturally, he
listens to the community, but I don't think there is much risk of him
allowing Ruby to become a "do everything, be everything" language (if
there even is such a thing). (Forgive me, matz, if I've put too many
words in your mouth here...)

So, my recommendation is for everyone to let good enough alone. I think
everyone with a strong opinion on the subject has stated their opinions,
and it looks like the mudslinging is about to start. And when that
starts, its as good of a place to stop the discussion as any. If there
is disagreement about the value of patches to the Ruby interpreter,
let's all just agree to disagree, please.

- Jamis

 

[trans. (T. Onoma)]

On Sunday 10 October 2004 10:28 am, David A. Black wrote:
| > Even so, I'm a nice guy. I feel for you. But you can't say I haven't
| > tried --I've pushed for a separate mailing list for this stuff for, lord
| > knows, how long now?
|
| OK... but maybe that means there's no interest in it...?  

Exactly, so why do people complain when those conversations occur here?

T.

 

[David A. Black]

Hi --

David, that's a little harsh. Tom has pushed his suby-muse list in a
very non-aggressive way, trying to get interested readers to the list.

You've misunderstood -- I didn't mean he'd done it wrong -- on the
contrary, I meant that he shouldn't feel exasperated for lack of
trying. ("It" in my sentence meant the separate list, not the various
flavors of discussion about changing Ruby.)


David

 

[Randy W. Sims]

Know what noise is? Another word for static. Know what static is? Something
that never changes. You know what something that never changes is?

S T A B L E

D E P E N D A B L E

C O M P A T I B L E

Like standards based languages: C, C++, Ada, etc.

Actually, this is the wrong argument. I don't think anyone is against
change. But some of us feel that there are some potential problems or
dangers associated with this particular change.

A long time ago I was reading one of Bjarne Stroustrup's books or on his
website where he proposed user defined operators. At the time I was
excited about it and looked forward to it. Unicode provides lots of neat
symbols that would make meaningful operators. If this patch allowed
that, I might be more inclined to agree with it. But that's the heart of
the problem: assigning meaning to an arbitrary combination of symbols
makes the resulting code hard to interpret. Among the objections listed,
I think this is the hardest to overcome. Some have compared operators to
methods, but that comparison doesn't really hold. IMO the only
comparison there is if you used method names like 'sdkjfo' - arbitrary
combinations of characters with no inherant semantics.

Regards,
Randy.

 

[trans. (T. Onoma)]

Well said Jamis, thanks.

T.


On Sunday 10 October 2004 10:42 am, Jamis Buck wrote:
| David, that's a little harsh. Tom has pushed his suby-muse list in a
| very non-aggressive way, trying to get interested readers to the list.
| (It's a great list, BTW. Low volume due to low membership right now, but
| the discussions have included fascinating dissertations on AOP and
| prototype-based languages. Great stuff.) People are obviously interested
| in discussing changes to the Ruby language itself (witness this thread).
|
| Part of the problem is--people want their ideas _heard_. And because of
| suby-muse's low volume, it is not a tempting target for many amateur
| language designers. So they post on ruby-talk and a flame-war ensues.
|
| Personally, I'm something of a fence-sitter in the current issue. I like
| the operators patch--goodness knows there have been times I've wanted to
| override operators in Ruby--but I've always found an acceptible (if not
| perfect) workaround. So obviously, Ruby as it is now is "sufficient."
|
| However, I think there is very little need to worry about Ruby becoming
| a "syntactic soup" as someone mentioned earlier. First of all, NONE of
| us have any real say in what goes into or stays out of Ruby. If matz
| likes an idea, he'll uses it. If he doesn't, he won't. Naturally, he
| listens to the community, but I don't think there is much risk of him
| allowing Ruby to become a "do everything, be everything" language (if
| there even is such a thing). (Forgive me, matz, if I've put too many
| words in your mouth here...)
|
| So, my recommendation is for everyone to let good enough alone. I think
| everyone with a strong opinion on the subject has stated their opinions,
| and it looks like the mudslinging is about to start. And when that
| starts, its as good of a place to stop the discussion as any. If there
| is disagreement about the value of patches to the Ruby interpreter,
| let's all just agree to disagree, please.
|
| - Jamis

--
( o _ カラãƒ
// trans.
/ \ (e-mail address removed)

I don't give a damn for a man that can only spell a word one way.
-Mark Twain

 

[Markus]

However, ISTM that what's being described here is a substantially different
language to Ruby.

Again, I think you are grossly overestimating what this patch does.

* Ruby already has a number of user definable operators, all
pulled from a set of operators characters.
* Ruby already gives users the ability to define any identifier
they want, by combining identifier characters in any order they
want, provided they don't conflict with a fixed set of keywords.

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

* 90% of the change is in the lexer (which defines the composition
of symbols).
* The only reason the parser (which defines the syntax of ruby) is
touched at all is to simplify prevention of conflicts with
existing code & simplify the generation of meaningful error
messages. All of the changes in the parser consist of
duplicating a rule under a different name, which DOES NOT CHANGE
THE SYNTAX at all.

Not only is the language not "substantially different" it isn't
technically different at all.

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.

Oh, that's just silly.

First of all, as I have made clear every time it came up, I am not
proposing (and will not propose) this for inclusion in the language
until/unless it can be shown to work in a way that does not break any
existing code, etc. We're not there yet.

Second, I have always found matz very open and able to perfectly
express himself. I don't need to "draw conclusions from his silence"
since I'll have ample opportunity to draw conclusions from whatever he
says if and when he says anything.
If I were to guess, I'd guess that he's waiting to see if I can
even make it work; he certainly knows how tricky even small changes can
be to get just right, and has seen several example of my C-skills (or
relative lack there of) over the last five years. If I can't make it
work, why bother arguing it (present company excepted of course)?

Third, I would never want the users of any of my software to assume
that missing features are missing because they don't fit my overall
world view. Nor would I want them to assume that bugs were there
intentionally, or read my silence as criticism. I'm pretty sure from
past interactions with him matz fells the same way.

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.

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.

There is a very specific need for the patch, as discussed earlier
on this list.

People (~five cases in the last two months) are arguing for changes
in the semantics of core classes because (and often only because) they
can't duplicate the functionality and/or subclass/modify it to suit
their needs.
One of the main strengths of ruby is that if I want a class that is
kind of like Array, but has slightly different semantics, I can subclass
it, or build my own class and delegate, or just reimplement it from
scratch. I can to do this with almost any class.
But there are a few classes (Hash & Range are the most current
examples) where "special syntax" is used, so I can't reimplement them to
suit. More to the point, no one can. This leads to long discussion
about how some core class "ought to work" when in fact 99% of the people
would be perfectly happy if they could roll their own versions as they
can with all the other classes.

Ultimately, my goal is to provide a way to _increase_ the stability
of the core language (compiler + base classes) by reducing the pressure
for changes.

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

Exactly the same problem arises with identifiers. Why aren't you
calling for a limit on user defined method names?

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

No offence taken. In the (yikes!) twenty six years since I was
first paid to design and implement a language I've been called things a
lot worse. "Wannabe language designer" sounds a lot fresher and more
optimistic (i.e. younger) that "crotchity semi-retired language
designer," so it's sort of a complement.

Now if people would only take me for a kid in person as readily as
they do on-line. *sigh*

-- Markus

 

[Markus]

I agree with almost all of your post, except:

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.

It's really no different than methods; the interpretation of the
operator is up to the receiver, exactly the same as with methods.
Operators are _already_ handled in the same way as methods.

-- Markus

 

[trans. (T. Onoma)]

01 AM, trans. (T. Onoma) wrote:
| > Know what noise is? Another word for static. Know what static is?
| > Something that never changes. You know what something that never changes
| > is?
|
| S T A B L E
|
| D E P E N D A B L E
|
| C O M P A T I B L E
|
| Like standards based languages: C, C++, Ada, etc.
|
| Actually, this is the wrong argument. I don't think anyone is against
| change. But some of us feel that there are some potential problems or
| dangers associated with this particular change.

I understand. Actually I've had a notion in the back of my head for awhile
about this. Seems to me developers might be better off if they followed
parallel tracks rather then serial tracks. Diagram:

Serial Model

0.x -> 1.0 -> 1.1 -> ... -> 2.0 -> 2.1 -> ... -> 3.0 -> ...


Parallel Model

0.x -> 1.0 -> 1.1 -> ... -> 1.x
|
V
2.0 -> 2.1 -> ... -> 2.x
|
V
3.0 -> ...

The idea is that bug-fixes and compatible-only changes move from left to
right, all and others move down. The only project I know that sort-of does
this much is Linux, but even there we see a lot of back porting and what not.

| A long time ago I was reading one of Bjarne Stroustrup's books or on his
| website where he proposed user defined operators. At the time I was
| excited about it and looked forward to it. Unicode provides lots of neat
| symbols that would make meaningful operators. If this patch allowed
| that, I might be more inclined to agree with it. But that's the heart of
| the problem: assigning meaning to an arbitrary combination of symbols
| makes the resulting code hard to interpret. Among the objections listed,
| I think this is the hardest to overcome. Some have compared operators to
| methods, but that comparison doesn't really hold. IMO the only
| comparison there is if you used method names like 'sdkjfo' - arbitrary
| combinations of characters with no inherant semantics.

I think there is a balance to be found. Many of us has wanted an extra
operator for this or that at one time or another. I tend to think that they
would be used sparingly if available for precisely the reasons people
suggested against them --but the "hard to read" arguments don't really
convince me that it wouldn't be a good feature --in fact in some cases it
would even make code clearer. And in fact that's why some people want this
feature --not to obscure code, but to actually make it easier to read.

T.

 

[Markus]

Actually, this is the wrong argument. I don't think anyone is against
change. But some of us feel that there are some potential problems or
dangers associated with this particular change.

Exactly why I value this discussion. I am very interested in
"potential problems" (as opposed to misunderstandings or groundless
fears). What, in particular, are people worried about? I've already
heard:

* Will break existing code (consequence: as a goal, the patch will
not be considered successful if it breaks _any_ existing code.
I even handled "proc {|x,*|x}" which I consider a bug).
* Will lead to namespace conflicts (consequence: I've tried to
clarify that this is not the case, since operators are
dispatched in the same way methods are (to the receiver))
* Will change the syntax of ruby, or turn it into "syntax soup"
(consequence: I've tried to clarify that this is not the case a
free posts back in this thread)

But I'm very interested in any specific problems you (or anyone
else) can see with the idea. I use ruby in production; I WANT IT TO BE
STABLE. The whole goal here is to remove the pressure to change the
semantics of core classes by letting people write their own versions
without being relegated to a syntactic ghetto. So I am as concerned as
anyone (maybe more; how many of you support over 20,000 lines of ruby
code in production use); I honestly want to know if there are any actual
problems with this, and what they are, in detail.

A long time ago I was reading one of Bjarne Stroustrup's books or on his
website where he proposed user defined operators. At the time I was
excited about it and looked forward to it. Unicode provides lots of neat
symbols that would make meaningful operators. If this patch allowed
that, I might be more inclined to agree with it.

Great idea. I'll look into it. (Though I suspect that that too may
raise some people's ire).

But that's the heart of the problem: assigning meaning to an arbitrary
combination of symbols makes the resulting code hard to interpret. Among
the objections listed, I think this is the hardest to overcome.

Harder for the compiler? Not really. Harder for humans? Perhaps,
if done poorly. But that depends on the choices the programmer makes.
You can write obsfucated code in any language, or even by misusing any
feature of any language. That doesn't mean that we shouldn't allow
languages to have features in general, does it?

Some have compared operators to methods, but that comparison doesn't
really hold. IMO the only comparison there is if you used method names
like 'sdkjfo' - arbitrary combinations of characters with no inherant
semantics.

This is a case of "trust the programmer"; people could in fact use
sdkjfo as an identifier (presumably to hold the software developers kit
java kernel object), but we trust them to be judicious.

For that matter, it may be _much_easier_ for most of the world's
population to interpret code written with a judicious choice of
user-defined operators than with clear and simple identifiers in a
language they don't speak fluently. I suspect we are all grateful that
matz didn't restrict identifiers to properly formed japanese phrases (to
prevent confusion of course), aren't we?

-- Markus

 

[Randy W. Sims]

01 AM, trans. (T. Onoma) wrote:
| > Know what noise is? Another word for static. Know what static is?
| > Something that never changes. You know what something that never changes
| > is?
|
| S T A B L E
|
| D E P E N D A B L E
|
| C O M P A T I B L E
|
| Like standards based languages: C, C++, Ada, etc.
|
| Actually, this is the wrong argument. I don't think anyone is against
| change. But some of us feel that there are some potential problems or
| dangers associated with this particular change.

I understand. Actually I've had a notion in the back of my head for awhile
about this. Seems to me developers might be better off if they followed
parallel tracks rather then serial tracks. Diagram:

Serial Model

0.x -> 1.0 -> 1.1 -> ... -> 2.0 -> 2.1 -> ... -> 3.0 -> ...


Parallel Model

0.x -> 1.0 -> 1.1 -> ... -> 1.x
|
V
2.0 -> 2.1 -> ... -> 2.x
|
V
3.0 -> ...

The idea is that bug-fixes and compatible-only changes move from left to
right, all and others move down. The only project I know that sort-of does
this much is Linux, but even there we see a lot of back porting and what not.

| A long time ago I was reading one of Bjarne Stroustrup's books or on his
| website where he proposed user defined operators. At the time I was
| excited about it and looked forward to it. Unicode provides lots of neat
| symbols that would make meaningful operators. If this patch allowed
| that, I might be more inclined to agree with it. But that's the heart of
| the problem: assigning meaning to an arbitrary combination of symbols
| makes the resulting code hard to interpret. Among the objections listed,
| I think this is the hardest to overcome. Some have compared operators to
| methods, but that comparison doesn't really hold. IMO the only
| comparison there is if you used method names like 'sdkjfo' - arbitrary
| combinations of characters with no inherant semantics.

I think there is a balance to be found. Many of us has wanted an extra
operator for this or that at one time or another. I tend to think that they
would be used sparingly if available for precisely the reasons people
suggested against them --but the "hard to read" arguments don't really
convince me that it wouldn't be a good feature --in fact in some cases it
would even make code clearer. And in fact that's why some people want this
feature --not to obscure code, but to actually make it easier to read.

I think we are mostly in agreement. It's all about balance. For example
the notation you used above in reference to versions conveys meaningful
information. (But let's hope no one actually tries to implement
vertically oriented operators. ;-) I just worry about abuses. How much
rope do you give the programmer? It's not always obvious. I guess I tend
to be more on the conservative side. When I first started learning Perl,
I thought I would hate it. Too much excess. Too many ways to say the
same thing. Coming from C/C++, I believed the core language should be as
small as possible so as to reduce comlexity, to be well-defined. Perl
turned out to be one of my favorite languages. So, I'm not completely
closed to the idea; I just have concerns.

Randy.

 

[Randy W. Sims]

Exactly why I value this discussion. I am very interested in
"potential problems" (as opposed to misunderstandings or groundless
fears). What, in particular, are people worried about? I've already
heard:

* Will break existing code (consequence: as a goal, the patch will
not be considered successful if it breaks _any_ existing code.
I even handled "proc {|x,*|x}" which I consider a bug).
* Will lead to namespace conflicts (consequence: I've tried to
clarify that this is not the case, since operators are
dispatched in the same way methods are (to the receiver))

This is potentially still a problem area since Ruby allows reopening
builtin classes. Particularly, I worry about the number classes and String.

* Will change the syntax of ruby, or turn it into "syntax soup"
(consequence: I've tried to clarify that this is not the case a
free posts back in this thread)

First, I'll admit that I haven't taken the time to examine the diff. But
I'm concerned with the types of changes that must be necessary to the
lexer that might reduce Ruby's ability to catch errors or potential
errors when scanning the source. I'm also still not convinced that it
can deal with gracefully with ambiguity.

But I'm very interested in any specific problems you (or anyone
else) can see with the idea. I use ruby in production; I WANT IT TO BE
STABLE. The whole goal here is to remove the pressure to change the
semantics of core classes by letting people write their own versions
without being relegated to a syntactic ghetto. So I am as concerned as
anyone (maybe more; how many of you support over 20,000 lines of ruby
code in production use); I honestly want to know if there are any actual
problems with this, and what they are, in detail.




Great idea. I'll look into it. (Though I suspect that that too may
raise some people's ire).

I found the paper at:
<http://www.research.att.com/~bs/whitespace98.pdf>

I was hoping it might be taken as a hint. ;-) Actually, I don't see why
there should be any objections to using unicode characters as operators:
There are no conficts with the existing language. There are symbols
available that have obvious semantics. I can't think of any objections
as long as you limit the symbols that can be used so that only symbols
and not any "letters" are used.

Harder for the compiler? Not really. Harder for humans? Perhaps,
if done poorly. But that depends on the choices the programmer makes.
You can write obsfucated code in any language, or even by misusing any
feature of any language. That doesn't mean that we shouldn't allow
languages to have features in general, does it?

Perl is known as a write only language because of it's heavy use of
symbols. That really refers more to the special variables $_, $@, $!,
etc., but it's very much the same concept. They have no obvious semantics.

This is a case of "trust the programmer"; people could in fact use
sdkjfo as an identifier (presumably to hold the software developers kit
java kernel object), but we trust them to be judicious.

I don't trust programmers. ;-)

For that matter, it may be _much_easier_ for most of the world's
population to interpret code written with a judicious choice of
user-defined operators than with clear and simple identifiers in a
language they don't speak fluently. I suspect we are all grateful that
matz didn't restrict identifiers to properly formed japanese phrases (to
prevent confusion of course), aren't we?

-- Markus

Randy.

 

[Markus]

This is potentially still a problem area since Ruby allows reopening
builtin classes. Particularly, I worry about the number classes and String.

I'm not sure what the problem is. Or rather, if there is a
problem, what it has to do with operators. I could write:

class String
def length
rand(super*2)
end
end

right now, and I assume all havoc would ensue. Should we then make
length a reserved word? For that matter, should we make it so the user
can't defined there own '+', etc. (which they can now) because it might
cause something bad to happen?

In any case, I don't see how this is a "namespace problem"; it
looks like maybe you'd like to finalize the core classes? There are
ways to do this, from preventing any modification to warning when it
happens. They would also catch operator definitions, since operators
are just methods.

First, I'll admit that I haven't taken the time to examine the diff. But
I'm concerned with the types of changes that must be necessary to the
lexer that might reduce Ruby's ability to catch errors or potential
errors when scanning the source. I'm also still not convinced that it
can deal with gracefully with ambiguity.

In a sense you are correct; things that would have been errors
before might now be meaningful, and thus not caught. This is the same
sort of thing that would happen if we only allowed /[a-z][0-9]?/
variable names and then decided that /[_a-z0-9]+/ was better: "x_axis",
which would have been an error, is now valid.
It may also be true in another, more troubling sense: some
combination of operators which was meaningful BP (before the patch) may
be meaningful in two distinct ways AP (after the patch). So how is the
compiler to decide? My answer (which so far seems to work) is to treat
all such cases as they would have been treated BP, but generate a
warning suggesting the use of space to eliminate the ambiguity Is that
sufficiently graceful?

I found the paper at:
<http://www.research.att.com/~bs/whitespace98.pdf>

Thanks, I'll take a look at it.

I was hoping it might be taken as a hint. ;-) Actually, I don't see why
there should be any objections to using unicode characters as operators:
There are no conficts with the existing language. There are symbols
available that have obvious semantics. I can't think of any objections
as long as you limit the symbols that can be used so that only symbols
and not any "letters" are used.

Over the years I have leaned that _anything_ can raise objections.
In my first language (late 1970's) I had to provide two trig libraries
because correcting a typo in the taylor series coefficients (a bug fix
if ever there was one) broke a customer's must-match-exactly test
suite. I had to support it through two releases (though it seemed much
longer) until they had a recertification and could accept the correct
answers.

Perl is known as a write only language because of it's heavy use of
symbols. That really refers more to the special variables $_, $@, $!,
etc., but it's very much the same concept. They have no obvious semantics.

If things had obvious semantics, we'd all be out of jobs.

But seriously, does '=>' have obvious semantics? Why are they so
different from "<="? Or how about the Range#member? vs. Range#include?
debate that's been going on for over a week now.

Programming is hard because it is easy to write things badly and
hard to write things beautifully. But languages with no operators are
as hard or harder to read (remember COBOL?) than languages with only
operators (remember APL?). Somewhere in the middle is the sweet spot,
and it varies from program to program. I can imagine cases that would
be much clearer with lots of operators, just as I can imagine cases that
would be clearer with lots of identifiers.

Again, unless we are going to restrict the language to something
that is useless, we will just have to trust the programmer to do the
right thing (or join a mailing list and razz them until they do).

I don't trust programmers. ;-)

*smile* Then you should lobby to outlaw computers.

-- Markus

 

[Brian Candler]

Parallel Model

0.x -> 1.0 -> 1.1 -> ... -> 1.x
|
V
2.0 -> 2.1 -> ... -> 2.x
|
V
3.0 -> ...

The idea is that bug-fixes and compatible-only changes move from left to
right, all and others move down. The only project I know that sort-of does
this much is Linux, but even there we see a lot of back porting and what not.

FreeBSD does exactly that (at the moment, 4.x = 'STABLE' and 5.x =
'CURRENT'; once 5.3 is released, it will become 'STABLE' and 6.x will become
'CURRENT'). Quite a bit gets back-ported from 5.x to 4.x though - it's not
as if it's a total project fork.

Regards,

Brian.

 

[gabriele renzi]

Markus ha scritto:

I agree with almost all of your post, except:




It's really no different than methods; the interpretation of the
operator is up to the receiver, exactly the same as with methods.
Operators are _already_ handled in the same way as methods.

Sure, what I mean is: it is possible that people could implement
Object#-> for,say, type conversion, and Integer#-> to build a range. It
is harder to have an overlap of #converto_to and #upto. Short names (and
I think operators should be short can easily cause problems, just
think of the (now deprecated) Object#id.

 

[Yukihiro Matsumoto]

Hi,

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

|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 KNOW thinking about enhancing the language is FUN. But let me
propose moving RCR related things to ruby-core for plain users' sake.

matz.

 

[Markus]

Hi,

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

|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 KNOW thinking about enhancing the language is FUN. But let me
propose moving RCR related things to ruby-core for plain users' sake.

matz.

I had originally tried to subscribe to ruby-core, but was
unsuccessful (auto rejection from the list server). I'll try again.

-- Markus

 

[George Moschovitis]

In what sense is this "diabetes"? I would take that to mean intolerance

I guess he means 'too much syntax sugar'

-g.

--
www.navel.gr | tel: +30 2106898050 | fax: +30 2106898437

Navel does not accept liability for any errors, viruses or omissions in
the contents of this message. The full corporate policy is available on
our site.

have fun: www.joy.gr

 

[Yukihiro Matsumoto]

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.

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.

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

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.

matz.