From: gabriele renzi <rff_rff@...>
Date: 2004-12-02T06:27:44+09:00
Subject: Re: Optional static typing (or, What can Ruby 2.0 borrow from Boo?)

Lothar Scholz ha scritto:
> Hello gabriele,
> 
> gr> Lothar Scholz ha scritto:
> 
> 
> gr> Anyway, notice that I submitted  RCR280 wich actually allow you to give
> gr> type assertions if you want them:
> 
> I must say that i don't like it because it mixes again runtime and
> compile time. i would really favour:
> 
> # if you want to add an integer to a subclass of Numeric
>  def sum a,b
>    assert_type "a => Numeric, b = Integer"
>    a+b
>  end

I understand what you mean. But given that compile time/runtime would be 
strongly intertwingled in ruby anyway (and that's a core part of it), I 
don't see a reason for it to behave diferently.

> Only if everything can be extracted statically (by looking at the code)
>  then you get into a better position then what is currently available.

well, I may had misunderstood it, but I thought that type hints in stuff 
like MzScheme were handled with something like partial evaluation on 
attributes that are normal runnable code.

>  Mixing another special feature like conversion into this is something
>  i absolutely don't like. Two different purposes should have to
>  different notations. Also your RCR makes the situation worse, adding
>  more invisble magic. But the main goal here is to be more verbose.

I did'nt meant to make it sound like magic :/
I understand your point that different things should have different 
notations.
But I was just thinking that I disliked the eterogenous world of 
Integer(), Hash[] and to_*, and I incidentally found that the conversion 
framework could have worked as a type system. And that adaption in 
python (Zope3/twisted Interfaces, PyProtocol/peak, pep246) worked very 
similar.


Anyway we just have a different opinion, but thanks for sharing your 
thoughts.