Re: Type Inference

On 28 Jan 2005, at 01:10, Curt Sampson wrote:

> On Fri, 28 Jan 2005, Eric Hodel wrote:
>
>> We've had this debate before.  Please go read the past discussions  
>> [1] before trying to bring something new to the table, or saying ruby  
>> needs 'X' to be successful.  Especially since we've got lots of ways  
>> to add typing to ruby already [2] [3].
>>
>> [1]  
>> http://www.google.com/search? 
>> q=site%3Ablade.nagaokaut.ac.jp+type+check
>> [2] http://people.freebsd.org/~eivind/ruby/types/
>> [3] http://mephle.org/StrongTyping/
>
> Wow, talk about missing the point.

No, I know exactly your point, but you are being very bad at expressing  
it.  Constantly saying that everybody is attacking you does not add  
credit to your statement, either.  Eivind Eklund  wrote a rather  
wonderful piece on exactly what you haven't expressed, but want to.   
Unfortunately its URL escapes me.

> 1. Ruby already has typing, in fact it already has strong typing. There
> is no way to apply an operation to (invoke a method on) an object where
> the operation is not suited to the type of the object.
>
> This is now about the third time we've gone around with people  
> attacking
> the idea of restricting how objects can be passed around based on their
> class, which I'm quite happy to attack, too. We're in full agreement  
> here!

The speed at which you have responded, and the way you are thinking you  
have been attacked indicate you haven't read nearly enough of the  
history of this debate in Ruby (if it all).  Only 3 hours is not enough  
to fully comprehend why what you want is hard in Ruby, and why people  
are perfectly happy the way things are.

Let me go back to your original statement, since that is your clearest  
post on your position to date...

> No, Ruby's implementation of [Duck Typing] is the problem. You can do  
> duck typing
> very much like Ruby does and still have statically checked types; you
> just need a type inference engine to do that for you.

I fully agree with you that a type inferencing engine can do this for  
you, but in Ruby it will be hard (the Self papers are the best  
reference on this).

> I think that that may actually be the next big step in popular
> programming languages. A lot of programmers these days expect that they
> will both never have a memory leak, and never have to track memory
> allocations and deallocations by hand. So we have garbage collectors.

Yep, its always great when the computer does things for us.  Nobody  
here will debate you on that.

> Soon people may see that it's perfectly reasonable to expect to be told
> at compile time type about type mismatches, and yet not have to keep
> track of types by hand, in the way that Java forces you to (and  
> prevents
> duck typing). So add a type inference engine or whatever you need for
> this.

Yes, this would benefit us greatly, except for one problem... There is  
no "compile time" in Ruby, there is only run-time.  (Self's type  
inferencing doesn't have a problem with having no "compile time", but  
Self has several advantages over Ruby.  Its biggest advantage is that  
Self has people who want to work on this problem working on this  
problem... Ruby doesn't).

And now back to the rest of your mail:

> So can we talk about TYPES, not classes, and maybe you can tell me
> what you disagree with about making Ruby a bit smarter about this sort
> of thing?

I agree Ruby should be as smart as it can about this, it is just hard  
(please see the Self papers and the history of this discussion on the  
mailing list).

> That an unmodified standard Ruby installation, attempts to
> execute the second statement of this complete program:
>
>     a = Object
>     a.not_a_method
>
> and then throws an exception is just silly. Any bozo can just look at  
> it
> and say it's not going to work. A computer can look at much more  
> complex
> things and say it's not going to work.

Ok, here is your much more complex thing, but not too complex, but I  
cannot tell if it is going to work until I run it:

srand Time.now.to_i

Thread.start do
   sleep rand(1)
   ObjectSpace.each_object(Object) do |o|
     def o.not_a_method() end
   end
end

a = Object.new
a.not_a_method # not_a_method may or may not be defined here

No "compile time" type inferencer can tell you if that is going to work  
or not.  A run-time type inferencer needs to do lots of things to tell  
you if that is going to work, and even still, it may not know that  
a.not_a_method is going to work until just before you try to call  
a.not_a_method.

This is why you feel your ideas are being attacked so much.  You cannot  
be certain that a.not_a_method will work until, at best, just before  
you are about to call it and nobody can take your execution timeslice.

The type inferencer must do a lot of work just before you try something  
to tell you if it failed or not.  I can get an identical message by  
just trying it, and for everybody that is shooting you down, that's  
exactly what they are comfortable with.

We like duck typing, and we're perfectly happy that exceptions are  
raised when things won't work.

Oh, and one more:

begin
   a = Object.new
   a.not_a_method # The type inferencer must not give up here!
rescue
   class Object; def not_a_method() end; end
   retry
end

(Yes, I've used code exactly like this to do rapid prototyping, its  
incredibly cool.)

-- 
Eric Hodel - [e-mail] - http://segment7.net
FEC2 57F1 D465 EB15 5D6E  7C11 332A 551C 796C 9F04