From: Michael Neumann <neumann@...>
Date: 2001-05-15T23:49:42+09:00
Subject: [ruby-talk:15165] Re: Discussion on new Ruby features

Christian Szegedy wrote:
> Sorry, I don't know how to reply to this list,
> so my replay will probably create a new thread.
> 
> Michael Neumann wrote:
> > or perhaps with additional range checking: 
> > 
> > def addInteger(a :< Fixnum, b > 0 : Fixnum) 
> > end
> 
> I don't understand the syntax of the first parameter, but generally,
> I support your idea. Additional constraint would also enhance 
> optimization possibilities.

It should denote that a is a subclass of Fixnum, kind_of?, instead is_a?.



> > Of course sometimes it would be nice to check for types this way,
> > but it's not often enough used, I guess.
> >
> > For that you could befine a method "must" in Object (like the one
> > in amstd), which can be used this way:
> >
> >  a.must Fixnum
> >  And raises an exception if the type is not equal.
> 
> I find the it less readable, and less suggestive and less effective
> (in terms of possible runtime, assuming optimal implementation of
> the above feature). To effectiveness: consider the following piece
> of code:
> 
>   def f(x : X)
>   end
> 
>   def g(x : X)
>      f(x)
>   end
> 
> A good compiler would easily eliminate the second check, but also
> a single check could be more effectively performed than now.

But it would not be 100% safe, because you could do for example the following:

  def f(x : X)
  end

  def g(x : X)
    Object.const_set("X", Y)  # now X is Y
    f(x)
  end

But of course, you would normally don't do it and there should be no problem with it.


> > What you could do is define an interface definition, and check if the
> > object "implements" this interface.
> > But this could be done in pure Ruby, I think.
> 
> I agree. Ruby is easy to write, extremely extandable. BUT: hard to optimize.
> Of course, extandability is an important issue and we should not give it up
> or even reduce it.
> 
> I think that the current freeze machanism, and perhaps an optional  more 
> agressive one, which does not allow unfreeze at all, e.g something like that:
> 
>    frozen class X
>       ... 
>    end

Try:

  class X; end
  X.freeze

  def X.new_method
  end

  # => can't modify frozen object


Of course, it's dynamic and cannot be used easily by the compiler.
But your example above could serve as a compiler-hint due to the fact
that it would be a syntax-enhancement. 

But who uses #freeze ? I don't think most of the Ruby-programmers use it.

> would also be an interesting feature, worth considering and could be
> essential for the usability of such features.
> 
> For a Ruby code compiled to C, one could consider different scenarios:

You may also look at r2c (Ruby to C compiler) or there is a JIT for Ruby.
But both are for 1.4.6 and I don't think they are really usable.
Or maybe you just wait until matz releases the bytecode-compiler for Ruby :-)

Regards,

Michael


-- 
Michael Neumann
merlin.zwo InfoDesign GmbH
http://www.merlin-zwo.de