ANN: Free-form-operators patch

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

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 :slight_smile:

Markus ha scritto:

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 like the idea of free form operators and actually I'd like even prefix freeform ops, if this patch allow them :slight_smile:

In article <1097255312.3754.1147.camel@lapdog.reality.com>,

···

Markus <markus@reality.com> wrote:

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

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

     -- Markus

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

···

On Fri, 2004-10-08 at 10:35, vruz wrote:

> 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 :slight_smile:

gabriele renzi wrote:

Markus ha scritto:

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 like the idea of free form operators and actually I'd like even prefix freeform ops, if this patch allow them :slight_smile:

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

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

···

On Fri, 2004-10-08 at 11:44, gabriele renzi wrote:

Markus ha scritto:
> 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 like the idea of free form operators and actually I'd like even prefix
freeform ops, if this patch allow them :slight_smile:

Markus said:

···

On Fri, 2004-10-08 at 11:44, gabriele renzi wrote:

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

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

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

···

On Fri, 2004-10-08 at 11:54, Hal Fulton wrote:

gabriele renzi wrote:
> Markus ha scritto:
>
>> 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 like the idea of free form operators and actually I'd like even prefix
> freeform ops, if this patch allow them :slight_smile:
>

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

> > bugs. My intent is that it won't break _any_ existing code.
> Eeeeeeeeeeeeeeeeee-vil !!
> Eeeeeeeeeeeeeeeeeeeeeee-vil !!
> hehehe
> have fun :slight_smile:
     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

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

···

On Fri, 2004-10-08 at 12:17, Jason Voegele wrote:

Markus said:
> On Fri, 2004-10-08 at 11:44, gabriele renzi wrote:
>> I like the idea of free form operators and actually I'd like even
>> prefix freeform ops, if this patch allow them :slight_smile:
>
> 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.

Markus wrote:

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?

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. :wink:

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

Jason Voegele wrote:

Markus said:

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

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.

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.

···

On Fri, 2004-10-08 at 11:44, gabriele renzi wrote:

      * It makes the parser about 150 lines shorter

Wow, amazing! Sounds like you found a way to generalize
what used to be code handling the existing operators
separately?

That would seem to be quite a positive development,
regardless of whether the generalized free-form operators
are (ultimately) to be allowed in standard Ruby.

Nice work !

Regards,

Bill

···

From: "Markus" <markus@reality.com>

Jason Voegele ha scritto:

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.

wow, and I thought Eiffel was one of those non funny languages :slight_smile:

Note that even Haskell has [^a-z] as operators, and even the funny thing that x `foo` y works as foo(x y)

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

I guess he means 'too much syntax sugar' :slight_smile:

-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

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

     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

···

On Fri, 2004-10-08 at 12:43, Hal Fulton wrote:

Charles Hixson wrote:

> .< 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. :wink:

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.

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.

···

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.

Hal Fulton <hal9000@hypermetrics.com> writes:

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. :wink:

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