headers
Nathan Weston | 1 Oct 2003 01:19
Favicon

Making == symmetric?

It has always bothered me that == is not symmetric in ruby: 
a == b is shorthand for a.==(b), while b == a is shorthand for
b.==(a), and a and b might not agree on whether they are equal.

I have an idea as to how to fix this, and was thinking of posting an
RCR on rubygarden, but I thought I'd post here first and see if I've
missed any major problems.

First of all: yes, this issue does come up in real code.
Here's a quick example I ran into today:

require "delegate"

class Foo
end

class D < SimpleDelegator
  def initialize(obj)
    super(obj)
  end
end

f = Foo.new
d = D.new(f)

d == f  #evaluates to true
f == d  #evaluates to false

I ran into a similar problem trying to implement perl6-style
junctions: you end up with any(1,2,3) == 1 being true, but 1 ==
(Continue reading)

Permalink | Reply | 21 comments |
headers
Thomas Sondergaard | 1 Oct 2003 01:19

Re: Article on ARTIMA

First, let me say that the original posting very clearly represents my
sentiments. Ruby the language rocks, the implementation... not so much.

> Slow: yup, slower than Python, C, Assembly and most other things... not a
> big issue for me most of the time, however.

Me neither, but without even thinking contientiously about it runtime
performance has influence on when I find ruby suitable for a project. If
ruby could be made a faster performer it would make more projects ruby
projects.

> Does not support native threads: not a major issue for me, but maybe for
> some people it is.

On Windows threading is *the* issue, if you ask me. It simply doesn't work.
It is incredibly counter-intuitive, as a thread model, that a *blocked*
thread prevents the other threads from running. Bizarre. Perfectly
comprehensible considering the implementation, but it just makes threading
on windows suck.

> Does not do JIT compilation or bytecode: nope... not a major issue for me

Well who cares how it is implemented, you already addressed your lack of
concern for the runtime speed.

> Needs a better GC: really?  Not for me.

I was not aware of this problem either.

>  ... I'd be curious to see how Ruby 1.8 fares
(Continue reading)

Permalink | Reply | 0 comments |
headers
Josef 'Jupp' Schugt | 1 Oct 2003 01:32
Picon
Picon
Gravatar

'the art of quoting' or 'FAQ: links that should be added'

Hi!

I first wanted to send the following in a PM to Hal but facing the
recent TOFU (Text On-top of Fullquote) orgies posting it seems to be
a better idea.

The German version of the FAQ has a pointer to http://learn.to/quote
(that's 'Wie zitiere ich im Usenet?' by Dirk Nimmich). An english
version (the translation is not *that* good but good enough) entitled
'How do I quote correctly in Usenet?' does exist and is available at

    http://www.netmeister.org/news/learn2quote.html

I think this text should be linked in the english version.

Because many formal issues result from the use of OE the german
version also has a pointer to the 'FAQ zu Microsoft Outlook Express'.
There seems to be no translation but there is a similar page in
English available at

    http://insideoe.tomsterdam.com/faqs/index.htm

I suggest to add this to the original FAQ, also.

Please take notice of signature! / Bitte Signature beachten!

Josef 'Jupp' Schugt
--

-- 
*Warning!* For sending me messages > 100 kB you need my explicit
permission. Otherwise they will be silently discarded.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Austin Ziegler | 1 Oct 2003 01:54
Picon

Re: Making == symmetric?

On Wed, 1 Oct 2003 08:19:27 +0900, Nathan Weston wrote:
> It has always bothered me that == is not symmetric in ruby: a == b is
> shorthand for a.==(b), while b == a is shorthand for b.==(a), and a and b
> might not agree on whether they are equal.
> 
> I have an idea as to how to fix this, and was thinking of posting an RCR
> on rubygarden, but I thought I'd post here first and see if I've missed
> any major problems.
> 
> First of all: yes, this issue does come up in real code. Here's a quick
> example I ran into today:
> 
> require "delegate"
> 
> 
> class Foo
> end
> 
> 
> class D < SimpleDelegator
> def initialize(obj)
> super(obj)
> end
> end
> 
> 
> f = Foo.new
> d = D.new(f)
> 
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Lothar Scholz | 1 Oct 2003 02:00

Re: Article on ARTIMA

Hello Bob,

Tuesday, September 30, 2003, 10:19:15 PM, you wrote:

>>From the talkback:

BX> "Ruby is over 10 years old, very popular in Japan, gaining popularity in
BX> other parts of the world, have thousands of users and hundreds of hackers.
BX> However, the implementation (Ruby has only 1 currently, written in C) is
BX> pretty weak. It's slow, does not support native threads, does not do JIT
BX> compilation (not even bytecode), needs a better GC, etc. It is especially so
BX> if we compare it with Java and Smalltalk, who have gotten real good
BX> implementations (JIT compilers, fast GC, threads, etc) nowadays."

BX> Comments?

100% ACK. The poster described the technical problems of ruby very
well. And they are a reason for not choosing the language in some
projects.

I really don't like native threads programming at the low level that
most languages offer (introduced 30 years ago - mutexes, semaphores
etc). Eiffel and TCL have much better way separating
threads and using message passing as the only way for communication.
I wish someone would take a look at TCL how to implement it, but the
current C implementation of ruby is such a hack that it is impossible to
add something like this.

And another thing is very important and should really be done if ruby
wants to escape the hacker world:
(Continue reading)

Permalink | Reply | 4 comments |
headers
Hal Fulton | 1 Oct 2003 03:20

Re: Article on ARTIMA

Lothar Scholz wrote:
> And another thing is very important and should really be done if ruby
> wants to escape the hacker world:
> 
> A Formal description of the language (you know the "language lawyer"
> section of the python documentation). JRuby and Ruby are not the same
> in some details and this is the result of the lack of specification.

This interests me. David Alan Black and I have discussed it more
than once.

But I'm not sure Matz likes the idea of a formal language spec. Or
perhaps he would say the spec already exists, and it is written
in C.

Matz? What would you think of a formal spec as long as 1) the content
was OK'd by you and 2) you didn't have to write it?

Hal
Permalink | Reply | 2 comments |
headers
Mark Wilson | 1 Oct 2003 03:42
Picon

Re: Article on ARTIMA


>  "Ruby is over 10 years old, very popular in Japan, gaining popularity 
> in
> other parts of the world, have thousands of users and hundreds of 
> hackers.
> However, the implementation (Ruby has only 1 currently, written in C) 
> is
> pretty weak. It's slow, does not support native threads, does not do 
> JIT
> compilation (not even bytecode), needs a better GC, etc. It is 
> especially so
> if we compare it with Java and Smalltalk, who have gotten real good
> implementations (JIT compilers, fast GC, threads, etc) nowadays."

Two thoughts on this:

1. Matz has discussed on this list what is expected to be handled in 
1.9 and 2.0. 1.9 will reimplement the interpreter. Matz anticipates a 2 
to 3 times speed increase from doing this. 1.9 will also include 
built-in support for multi-byte characters and will deal with the 
scoping of variables within blocks. 2.0 will introduce a Ruby virtual 
machine with byte-code compilation. Parrot will be an independent 
virtual machine for Ruby, Perl and Python (and maybe more?).

2. The comment is the other side of the coin, so to speak, in relation 
to what Matz was talking about in the interview. Matz has been focused 
on the human interaction with the language because he thinks its the 
most important part. The comment focuses on the language's interaction 
with the hardware, which is considered less important by Matz. But it 
certainly is not being ignored.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Wilson | 1 Oct 2003 04:16
Picon

Re: Making == symmetric?

Those more knowledgeable than me should correct what I've written below 
if it's wrong.

On Tuesday, September 30, 2003, at 07:19 PM, Nathan Weston wrote:

> It has always bothered me that == is not symmetric in ruby:
> a == b is shorthand for a.==(b), while b == a is shorthand for
> b.==(a), and a and b might not agree on whether they are equal.

I think it is symmetric so long as you bear in mind that the method 
belongs to the object and not to the variable that refers to the 
object. See below.

> [snip]

> First of all: yes, this issue does come up in real code.
> Here's a quick example I ran into today:
>
> require "delegate"
> class Foo
> end
> class D < SimpleDelegator
>   def initialize(obj)
>     super(obj)
>   end
> end
> f = Foo.new
> d = D.new(f)
> d == f  #evaluates to true
> f == d  #evaluates to false
(Continue reading)

Permalink | Reply | 8 comments |
headers
Ben Giddings | 1 Oct 2003 05:49

Re: Making == symmetric?

Nathan Weston wrote:
> def compare(a,b)
>    if a.can_compare_to?(b)
>       return a.compare_to(b)
>    elsif b.can_compare_to?(a)
>       return b.compare_to(a)
>    else
>      return false
>    end
> end

How about

def compare(a, b)
   retval = false
   if a.can_compare_to(b)
     retval = a.compare_to(b)
   end
   if retval and b.can_compare_to(a)
     retval = b.compare_to(a)
   end

   return retval
end

This way if both of them know how to compare themselves to the other one, 
the comparison returns true only if both agree they're equal.

Aside from the code though, I'm not sure if I like the idea.  While in 
principle I agree that equality tests should be symmetrical, I also think
(Continue reading)

Permalink | Reply | 3 comments |
headers
Yukihiro Matsumoto | 1 Oct 2003 06:03
Favicon
Gravatar

Re: Article on ARTIMA

Hi,

In message "Re: Article on ARTIMA"
    on 03/10/01, Hal Fulton <hal9000 <at> hypermetrics.com> writes:

|Matz? What would you think of a formal spec as long as 1) the content
|was OK'd by you and 2) you didn't have to write it?

Definitely it's good to have, unless it slows down the language
evolution.

							matz.
Permalink | Reply | 1 comment |

Gmane