Optional static typing (or, What can Ruby 2.0 borrow from Boo?)

ruby-talk
21

Hello gabriele,

Lothar Scholz ha scritto:

Anyway, notice that I submitted RCR280 wich actually allow you to give
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

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

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.

The assert_type could be extended to help with collections and other
things a little bit:

assert_type "h => Hash[Integer], object.foo = String, @myvar = Dummy"

I think there are many more things left for discussion but my
"must do" points are:

1) Don't make the implementation of this customizable to non ruby core
   hackers.

2) Use a special syntax if this is better for readability.
   To do this independent of ruby i suggest to embedd this into a string
   notation. And enforce that the argument is a literal. (Can easly be
   done from the C side).

3) Type constraints are type constraints and nothing else.

4) A program must run exactly the same if you disable the implementation.

5) Don't allow any tricky or shortcuts for lazy programmers.

···

--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's

22

Hi --

···

On Wed, 1 Dec 2004, Lothar Scholz wrote:

Hello gabriele,

> Lothar Scholz ha scritto:

> Anyway, notice that I submitted RCR280 wich actually allow you to give
> 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

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

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.

The assert_type could be extended to help with collections and other
things a little bit:

assert_type "h => Hash[Integer], object.foo = String, @myvar = Dummy"

If you're going to write this, or propose it as an RCR, it would be
better to call it "assert_class", or "assert_isa", to keep clear the
important distinction between type and class in Ruby and the fact that
this is a class-name/hierarchy check, rather than a type check.

David

--
David A. Black
dblack@wobblini.net

23

Lothar Scholz ha scritto:

Hello gabriele,

> Lothar Scholz ha scritto:

> Anyway, notice that I submitted RCR280 wich actually allow you to give
> 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 :confused:
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.