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

[Austin Ziegler]

Hi all,

I was just looking at http://boo.codehaus.org/BooManifesto.pdf.
One thing I really kinda like is the optional static typing.
Wouldn't this allow potential compile time error checking and
optimization with a virtual machine running things? I imagine the
syntax looking something like this:

def foo(String s, Hash h)
...
end

I don't like that because it then suggests that this should be
possible:

def foo(String s, Hash h)
end

def foo(Integer s, Hash h)
end

This seems to regress from what I have come to know and love in
Ruby. As I've said, I think that the main purpose for typing hints
is for language interop (e.g., SOAP, CORBA, etc.) so that we can
meaningfully provide services without having to write a lot of
supporting code. I've had a couple of thoughts regarding this.

The first thought comes from C# attributes:

[Attribute(parameters)]
void foo(...) { ... };

Obviously, this won't quite work in Ruby as is, but we don't tag
anything with <>, e.g.:

<parameters(String, Hash)>
<parameters(Integer, Hash)>
def foo(s, h)
end

Strictly speaking, such markup isn't necessarily even "necessary":

parameters String, Hash
parameters Integer, Hash
returns String
def foo(s, h)
end

The "parameters" portion is already feasible because of the
#method_added hook (e.g., you collect the arguments passed to
"parameters" until you see a method definition). Hooking into the
calling of methods is a bit harder, but you could provide heavy,
light, or zero class checking with a bit of work in the interpreter
itself.

I don't see great value in type hinting -- and static typing is a
big lose in Ruby, I think (type inferencing, on the other hand, is
valuable). This might actually be something that can be done, and
done without really harming the flexibility of Ruby.

I like the idea of metadata attributes being added right in the
code; if it's Ruby, that's even neater -- but I don't want to see
type tags put right in the method definition, because I think that
will reduce the overall flexibility of code.

-austin

 

[gabriele renzi]

Austin Ziegler ha scritto:

I don't like that because it then suggests that this should be
possible:

def foo(String s, Hash h)
end

def foo(Integer s, Hash h)
end

This seems to regress from what I have come to know and love in
Ruby.

well, but is'nt multimethod dispatch something useful ?
I'm thinking of cases like:
class Foo
def initialize(foo)
case foo
when Integer
do stuff
when String
do other stuff
end
end
end

which is inextensible withouth changing the method source, while with
MMD a specialized method can be provided from anyone.
Not that this needs a special syntax, as florian gross demonstrated some
time ago

I don't see great value in type hinting -- and static typing is a
big lose in Ruby, I think (type inferencing, on the other hand, is
valuable). This might actually be something that can be done, and
done without really harming the flexibility of Ruby.

static automagic interface inference yay!

 

[gabriele renzi]

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.