ANN: Free-form-operators patch

M

Markus

All --

This time instead of a long description I will give to you a long
URL:

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

Free form operators for ruby patch. Define your own --> and =~~ as you
see fit. Impress your friends. Confound your enemies. And it really
really works.

I hope.

The web page is pre-alpha but the patch is beta.

PLEASE let me know if you try this, and especially if you find any
bugs. My intent is that it won't break _any_ existing code.

-- Markus
 
V

vruz

PLEASE let me know if you try this, and especially if you find any
bugs. My intent is that it won't break _any_ existing code.


Eeeeeeeeeeeeeeeeee-vil !!

Eeeeeeeeeeeeeeeeeeeeeee-vil !!
hehehe

have fun :)
 
M

Markus

Eeeeeeeeeeeeeeeeee-vil !!

Eeeeeeeeeeeeeeeeeeeeeee-vil !!
hehehe

have fun :)

But...but...my _heart_ is pure!

-- Markus

P.S. Well, purer that some of my code at least.
 
P

Phil Tomson

All --

This time instead of a long description I will give to you a long
URL:

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

Free form operators for ruby patch. Define your own --> and =~~ as you
see fit. Impress your friends. Confound your enemies. And it really
really works.

I hope.

The web page is pre-alpha but the patch is beta.

PLEASE let me know if you try this, and especially if you find any
bugs. My intent is that it won't break _any_ existing code.

Cool... Nice toy...
I'm sure you learned a lot about Ruby's innards doing this.

Phil
 
H

Hal Fulton

gabriele said:
Markus ha scritto:



I like the idea of free form operators and actually I'd like even prefix
freeform ops, if this patch allow them :)

It is cool and interesting from a theoretical standpoint, but it causes me
to coin the term "syntax diabetes" (if someone hasn't already).


Hal
 
M

Markus

Markus ha scritto:

I like the idea of free form operators and actually I'd like even prefix
freeform ops, if this patch allow them :)

Not yet. I can see how to do it, but haven't quite finished thinking
through the details. I'd also like to have some way to control the
precedence/associativity/arity, but I haven't figured out a way to do it
that I'm sure could be made consistent.

-- Markus
 
J

Jason Voegele

Markus said:
Not yet. I can see how to do it, but haven't quite finished thinking
through the details. I'd also like to have some way to control the
precedence/associativity/arity, but I haven't figured out a way to do it
that I'm sure could be made consistent.

FYI, Eiffel has user-defined prefix and infix operators. The language
rule is that all user-defined operators have a higher precedence than
built-in operators. The built-in operators follow typical precedence
rules.

--
Jason Voegele
"There is an essential core at the center of each man and woman that
remains unaltered no matter how life's externals may be transformed
or recombined. But it's smaller than we think."
-- Gene Wolfe, The Book of the Long Sun
 
M

Markus

It is cool and interesting from a theoretical standpoint, but it causes me
to coin the term "syntax diabetes" (if someone hasn't already).

Ok, I'll bite. Why? Some details:

* If you don't use it, it should have no effect (not true with
today's version, which has two known bugs at this moment, but
that's the goal).
* It makes the parser about 150 lines shorter
* It does not effect compile times
* It might make it possible to move some features out of the core
language and into libraries (if it were proposed and accepted as
something more than an experimental hack).
* It (with some of the other ideas that have been floated) would
reduce the pressure to add new features, and allow them to be
"community tested" before being added, by letting people
prototype their ideas without being relegated to a syntactic
ghetto.

In what sense is this "diabetes"? I would take that to mean intolerance
for syntactic sugar (it sends you into a coma or something). Or am I
missing your point?

-- Markus
 
M

Markus

Markus said:

FYI, Eiffel has user-defined prefix and infix operators. The language
rule is that all user-defined operators have a higher precedence than
built-in operators. The built-in operators follow typical precedence
rules.

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.

-- Markus
 
H

Hal Fulton

Markus said:
Ok, I'll bite. Why? Some details:

* If you don't use it, it should have no effect (not true with
today's version, which has two known bugs at this moment, but
that's the goal).
* It makes the parser about 150 lines shorter
* It does not effect compile times
* It might make it possible to move some features out of the core
language and into libraries (if it were proposed and accepted as
something more than an experimental hack).
* It (with some of the other ideas that have been floated) would
reduce the pressure to add new features, and allow them to be
"community tested" before being added, by letting people
prototype their ideas without being relegated to a syntactic
ghetto.

In what sense is this "diabetes"? I would take that to mean intolerance
for syntactic sugar (it sends you into a coma or something). Or am I
missing your point?

I can't argue with certainty that it's a bad thing. I'm strongly in favor of
experimentation, in fact.

It might even be a great thing in Ruby 1.9 -- but I (personally) would not
want to see it permanently in Ruby.

This is just my opinion, so don't take it the wrong way. And don't stop your
experimentation. ;)

I believe that a language should provide "all the power you need" but "not
too much more than you need." This is admittedly highly subjective.

As a silly example: Suppose we made Ruby's syntax so extensible that we could
bend and twist it pretty much any way we wished. It would only be days before
some people started writing "Ruby that wasn't really Ruby." For example, someone
would do: require 'ruby2pascal' and then the rest of his program would be in
Pascal syntax. Someone else would do the same with Ada and whatever else is
out there.

At that point, yes, I would definitely go into a coma.

Don't we see this happening to some limited extent already? I would say that
some of the libraries and coding techniques I have seen in the past five years
constitute "using Ruby's flexibility to undermine Ruby" -- if you will pardon
the analogy, rather in the same way that terrorists have taken advantage of the
freedoms in the USA to destroy those same freedoms. (I hesitated to type that
last sentence, because there is no genuine comparison between casual misuse
of a programming language and the taking of innocent lives. But I am speaking
in a purely abstract sense: A sufficiently open system can be turned against
itself to undermine that openness. Flames and political discussion will be
redirected to /dev/null).

I don't speak for Matz or claim any insight into his thought processes. However,
that is exactly what I *strive* to do -- I strive to think like Matz. And in the
light of things I have heard him say about macros, about continuations, and so on,

I'm ignorant of Lisp. (Do people get tired of hearing me say that?) But I note
that Matz is at least extremely cautious (I would say outright opposed) to having
macros in Ruby. And yet he admits that callcc is also very powerful, yet he permits
it to exist in Ruby. I perceive it as a balance.

Of course, even Matz is not the ultimate genius of this planet. But he has created
something very special in Ruby, in my opinion; something that could not have been
created by a committee. There are many other people I want to learn from; but at
the moment, he is at the top of my list.

I would be pleased if Matz agreed with what I say here. But I would also be pleased
if he disagreed, because that is another opportunity for me to learn.


Cheers,
Hal
 
M

Markus

This is just my opinion, so don't take it the wrong way. And don't stop your
experimentation. ;)

Oh, no worries. There's no risk of that.
I believe that a language should provide "all the power you need" but "not
too much more than you need." This is admittedly highly subjective.

The problem is, what if I want more power than you do? And what if
Angilena Mathmatica or Bob Business wants something that neither of us
do? I'd say that the language should provide enough flexibility for
everyone, so long as it's not required that anyone use it who doesn't
want it.
As a silly example: Suppose we made Ruby's syntax so extensible that we could
bend and twist it pretty much any way we wished. It would only be days before
some people started writing "Ruby that wasn't really Ruby." For example, someone
would do: require 'ruby2pascal' and then the rest of his program would be in
Pascal syntax. Someone else would do the same with Ada and whatever else is
out there.

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.
Don't we see this happening to some limited extent already? I would say that
some of the libraries and coding techniques I have seen in the past five years
constitute "using Ruby's flexibility to undermine Ruby" -- if you will pardon
the analogy, rather in the same way that terrorists have taken advantage of the
freedoms in the USA to destroy those same freedoms. (I hesitated to type that
last sentence, because there is no genuine comparison between casual misuse
of a programming language and the taking of innocent lives. But I am speaking
in a purely abstract sense: A sufficiently open system can be turned against
itself to undermine that openness.

Whoa. The only time I've seen "freedoms destroyed" is by people
arguing that there is somehow risk in too much flexibility/openness and
we need to clamp down on it "in order to save it." You aren't seriously
arguing that people using ruby in some way that you don't like is going
to "undermine ruby" are you?

And, as an aside, if you aren't wanting to start a political
discussion it's probably best not to compare the person you are writing
to to a terrorist. Just a thought.
I'm ignorant of Lisp. (Do people get tired of hearing me say that?) But I note
that Matz is at least extremely cautious (I would say outright opposed) to having
macros in Ruby. And yet he admits that callcc is also very powerful, yet he permits
it to exist in Ruby. I perceive it as a balance.

I too oppose macros. They are a semantic nightmare. But operators
(especially those exposed as methods) are as tractable as anything we
have in ruby now. The ONLY thing my patch does is let someone write

x <--> y

instead of having to write

x.pretent_this_is_two_headed_arrow(y)

It doesn't change the semantics at all.

-- Markus
 
H

Hal Fulton

Markus said:
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.

It depends on the context and the usage. I recall a shop (not mine, a friend
worked there) where management mandated that C would be used henceforth. But
these were diehard BASIC programmers. What they did was fulfill the minimum
requirement of using C by creating a "CBAS" layer ("looks like BASIC, tastes
like C") and mandating that junior programmers write to that layer. Sheer
madness.

But if you're talking about integrating SQL and such in useful, productive
ways, that is different.
You aren't seriously
arguing that people using ruby in some way that you don't like is going
to "undermine ruby" are you?

What I like is ultimately irrelevant. I admit that "good code" and "bad code"
are subjective terms; but we all use those terms, do we not? I'm saying it is
theoretically possible that someday the amount of bad code in Ruby could exceed
the amount of good code. That, in my opinion, would undermine Ruby.
And, as an aside, if you aren't wanting to start a political
discussion it's probably best not to compare the person you are writing
to to a terrorist. Just a thought.

I really truly never intended any such comparison. Please accept my apologies
for my poor phrasing.

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.


Cheers,
Hal
 
C

Charles Hixson

Jason said:
Markus said:



FYI, Eiffel has user-defined prefix and infix operators. The language
rule is that all user-defined operators have a higher precedence than
built-in operators. The built-in operators follow typical precedence
rules.
This is one place that I don't think Eiffel got things quite right.
Precedence should be defineable, not necessarily higher than all
built-in operators. If one is defining a cross-product, e.g., one
doesn't necessarily want it to be of higher precedence than whatever one
is using to define the literal representation of the matrix. And
ordinary arithmetic might be of even higher precedence. E.G.:

| .< 1 + 3, 5 * 2, 6 / 3 >. .<n21, n22, n23>. .<n31, n32, n33>. | .*. M
(To allow for varying type faces... there are no doubledots within that
expression. They are separated by spaces. Also, the vertical bars are
set off by spaces.
Interpretations:
| means start or end a matrix
< means start a row
. means end a row
*. means cross product
Perhaps this isn't the most elegant notation, but I created it off the
cuff, and even so I think it's fairly intelligible. But it wouldn't
work if the precedence didn't allow it. This means that .*. and | can't
have the same precedence.
 
C

Charles Hixson

Hal said:
...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.

Cheers,
Hal

OK. I will counter with the assertion that any system which centralizes
power will find the power turned to the benefit of those occupying the
positions of power, irrespective of the reasons for which the power was
centralized.

Ruby should be and remain open.
 
R

Randy W. Sims

Charles said:
| .< 1 + 3, 5 * 2, 6 / 3 >. .<n21, n22, n23>. .<n31, n32, n33>. | .*. M

A perfect example of why free-form-operators are a bad idea. ;-)

No offense intended. It's just that custom notations are not obvious to
readers/maintainers of the code. Also, adding such flexibility to the
parser means it is probably less capable of recognizing and diagnosing
errors. Then there is the problem of clashes when multiple extensions
try to define the same ops for entirely different operations.

Regards,
Randy.
 
C

Charles Hixson

Randy said:
A perfect example of why free-form-operators are a bad idea. ;-)

No offense intended. It's just that custom notations are not obvious
to readers/maintainers of the code. Also, adding such flexibility to
the parser means it is probably less capable of recognizing and
diagnosing errors. Then there is the problem of clashes when multiple
extensions try to define the same ops for entirely different operations.

Regards,
Randy.

And your proposed method of representing a matrix is??
I don't find:

M.backCross([[1 + 3, 5 * 2, 6 / 3 ], [n21, n22, n23], [n31, n32, n33] ] )

to be very intelligible, even if I wrote it. Do remember that matrix
multiplication isn't commutative, so the order is very significant. The
list ISN'T a matrix. It's a double list. Quite a different beast. One
can't make the same assumptions about it's organization, contents, etc.
And one doesn't want to define a matrix mulitplication on a list,
without being certain that it's a matrix.

I suppose one could do
Matrix([[1 + 3, 5 * 2, 6 / 3 ], [n21, n22, n23], [n31, n32, n33] ]
).cross(M)
which is a bit better, but not very good. (It couldn't really be the
Matrix class. That name is already taken, and doesn't act the way I
want. I use it because it's intelligible with minimal explanation.)

Specialized areas create specialized representations for very good
reasons. That you don't want to use them doesn't make them bad
representation, it means that you don't work in that area. Logicians
worked a long time developing good representation for symbolic logic.
They still don't have good translations into programming languages, even
though programming is an outgrowth of the same field. Not being able to
create representations for specialized forms cripples the development of
a field. That some bad representations will be created along the way
is, unfortunately, inevitable. It doesn't mean that allowing the
expression is bad, merely that developing good expressions is difficult.

Consider the number of flawed programs that are written. Extending your
argument only slightly would argue against allowing any programming
languages to exist.
 
T

trans. (T. Onoma)

On Friday 08 October 2004 03:43 pm, Hal Fulton wrote:
| It might even be a great thing in Ruby 1.9 -- but I (personally) would not
| want to see it permanently in Ruby.

I think there is a simple matter perspective here. It is okay for methods to
be of alphanumeric but not other characters (expect _ ? ! and =). "Operator"
methods on the other hand are not alphanumeric. That's great. But why can a
method be a an arbitrary length string, but an operator can not? It doesn't
seem fair. It's not fair to be so limited on operators.

I like this patch. I hope it eventually works well enough to make it into
Ruby.

An Independent Libertarian,
T.
 
V

vruz

bugs. My intent is that it won't break _any_ existing code.
But...but...my _heart_ is pure!
-- Markus

P.S. Well, purer that some of my code at least.

otoh, discussing about Kansas (an ORM lib by Kirk Haines)
Kirk came up with a case where he would like to redefine
the != (and others)

Quoting Kirk from IRC:

13:37 < wyhaines> Kansas lets one construct queries of the database
using Ruby statements. Basically, method_missing plus overrides
intercepts the Ruby and makes sense of it. So:
13:37 < wyhaines> ksdbh.select:)Foo) {|f| f.some_field == 'thingy'}
13:37 < wyhaines> works fine. However, an inequality is a problem
because != can't be overridden.
13:38 < wyhaines> I can do:
13:38 < wyhaines> ksdbh.select:)Foo) {|f| f.some_field.not_equal 'thingy'}
13:38 < wyhaines> but that's ugly. I haven't found any other option, though.


So there you go, in this scenario at least, the evil would be useful
and would make more readable code
 
M

Mikael Brockman

Hal Fulton said:
I can't argue with certainty that it's a bad thing. I'm strongly in
favor of experimentation, in fact.

It might even be a great thing in Ruby 1.9 -- but I (personally) would
not want to see it permanently in Ruby.

This is just my opinion, so don't take it the wrong way. And don't
stop your experimentation. ;)

I believe that a language should provide "all the power you need" but
"not too much more than you need." This is admittedly highly
subjective.

As a silly example: Suppose we made Ruby's syntax so extensible that
we could bend and twist it pretty much any way we wished. It would
only be days before some people started writing "Ruby that wasn't
really Ruby." For example, someone would do: require 'ruby2pascal' and
then the rest of his program would be in Pascal syntax. Someone else
would do the same with Ada and whatever else is out there.

At that point, yes, I would definitely go into a coma.

Don't we see this happening to some limited extent already? I would
say that some of the libraries and coding techniques I have seen in
the past five years constitute "using Ruby's flexibility to undermine
Ruby" -- if you will pardon the analogy, rather in the same way that
terrorists have taken advantage of the freedoms in the USA to destroy
those same freedoms. (I hesitated to type that last sentence, because
there is no genuine comparison between casual misuse of a programming
language and the taking of innocent lives. But I am speaking in a
purely abstract sense: A sufficiently open system can be turned
against itself to undermine that openness. Flames and political
discussion will be redirected to /dev/null).

To continue the analogy: restricting the flexibility of Ruby to prevent
syntax abuse is analogous to restricting the freedom of the U.S. to
prevent terrorist abuse (e.g., by mechanisms like the PATRIOT act).

``Those who would give up Essential Liberty to purchase a little
Temporary Safety, deserve neither Liberty nor Safety.''
-- Benjamin Franklin

(Sorry, but you were practically asking for it. :))
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,769
Messages
2,569,579
Members
45,053
Latest member
BrodieSola

Latest Threads

Top