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

[Daniel Berger]

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

Keeping in mind that it could also be written as just:

def foo(s,h)
...
end

If the types were not provided, then no compile time optimization or
error checking would occur.

What about an optional return type? Something like?

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

And this could be mixed with the optional static typing:

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

Everything else from the manifesto looks possible already in Ruby,
except for the macros, which I know Matz opposes.

Oh, and if it's not too late, I wouldn't mind replacing '@' with a
single leading underscore for instance variables.

What do folks think? Or is this just too difficult to implement?

Regards,

Dan

 

[Nikolai Weibull]

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?

Finally, a thread on static versus dynamic typing in Ruby!
nikolai

 

[David G. Andersen]

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:

http://www.rubygarden.org/ruby?Rite

"Optional typing

matz finds the current typing systems (StrongTyping? and types.rb)
based on class/modules are too restrictive and hinder duck typing.
He's looking for ideas to implement a system based on method
signatures and integrate it in the VM core."

See also Matz's "How Ruby Sucks" presentation, and the slides
from this year's RubyConf 2004:

http://www.zenspider.com/Languages/Ruby/RubyConf2004.html

Koichi Sasada's talk on "YARV: Yet Another RubyVM" was interesting
in this regard:

http://www.atdot.net/yarv/RubyConf2004_YARV_pub.pdf

though it didn't explicitly talk about handling type information.

-Dave

 

[gabriele renzi]

Daniel Berger ha scritto:

Hi all,

I was just looking at http://boo.codehaus.org/BooManifesto.pdf. One
thing I really kinda like is the optional static typing.

IIUC in boo is the contrary. It has optional duck typing, but it is
strongly typed (with type inference)

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 think that teorically optimization can be done from a jit even
withouth type hinting. Psycho for python and various SmallTalk do this.
But optional typing is interesting for documentation and early failing
purposes. Matz is thinking about this, so feel free to write an rcr

But In case we had optional typing I'd prefer to see types as full
predicates, instead of simple is_a? checks.

 

[David A. Black]

Hi --

Daniel Berger ha scritto:


IIUC in boo is the contrary. It has optional duck typing, but it is
strongly typed (with type inference)


I think that teorically optimization can be done from a jit even
withouth type hinting. Psycho for python and various SmallTalk do this.
But optional typing is interesting for documentation and early failing
purposes. Matz is thinking about this, so feel free to write an rcr

But In case we had optional typing I'd prefer to see types as full
predicates, instead of simple is_a? checks.

They would have to be, because is_a? doesn't tell you about the
object's type, just its class/module hierarchy.

And then, when a typing system becomes complicated enough, with enough
granularity to even begin to hint at the possibilities embodied in
Ruby objects, it will start to converge on what was there all along
anyway -- dynamism, uncertainty, change -- and will be superfluous


David

 

[gabriele renzi]

David A. Black ha scritto:

They would have to be, because is_a? doesn't tell you about the
object's type, just its class/module hierarchy.

And then, when a typing system becomes complicated enough, with enough
granularity to even begin to hint at the possibilities embodied in
Ruby objects, it will start to converge on what was there all along
anyway -- dynamism, uncertainty, change -- and will be superfluous

I guess the type theorist out there would not agree (i.e. I'm told is
easy to define Odd or Prime types in haskell). And even if agree that it
may converge on what we have now, I still see a great value in crash
early behaviour and documentation.
I'm not the one to revolutionize ruby, I just want a slight enhancement

 

[Florian Gross]

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 agree that optional static typing is a nice thing to have, if only for
providing optimization hints though it looks like in a perfect world
Hotspotting and runtime type information would be used. I am no expert
in this area so take my claims with a grain of salt.

However the syntax you propose is not going to work out. If parameters
can be typed the same should apply for variables. That would look like
this with your syntax:

String s = "hello"
Hash s = {1 => 2}
Float s = 5.0

But note that this is already valid syntax in Ruby and the latter
doesn't even raise a NoMethodError:

irb(main):018:0> Float s = 5.0
=> 5.0

So I think we would need another syntax for this if it were to be
implemented.

 

[David A. Black]

Hi --

David A. Black ha scritto:


I guess the type theorist out there would not agree (i.e. I'm told is
easy to define Odd or Prime types in haskell).

But I'm talking specifically about Ruby, not theorizing about type in
general.


David

 

[Phil Tomson]

Finally, a thread on static versus dynamic typing in Ruby!
nikolai

Oh no, not another one.

Quick, duck! (or perhaps I should say, Super Duck (type) to the rescue!)

[Often red gemstones are used to represent Ruby, but perhaps we should
consider a duck of some sort. Maybe even an ascii-art one we can drag
out for these occasions.]

Phil

 

[Nikolai Weibull]

[Often red gemstones are used to represent Ruby, but perhaps we should
consider a duck of some sort. Maybe even an ascii-art one we can drag
out for these occasions.]

(This was actually proposed a while ago, but we have been unable to find
a good picture without a copyright.)

Or perhaps an email-thread with a "Subject: Static typing in Ruby"?
The ASCII-art version will be easy enough to create. An icon may be
harder...
nikolai

 

[Phil Tomson]

[Often red gemstones are used to represent Ruby, but perhaps we should
consider a duck of some sort. Maybe even an ascii-art one we can drag
out for these occasions.]

(This was actually proposed a while ago, but we have been unable to find
a good picture without a copyright.)

Why not have Why_the_lucky_stiff draw us one? The guy's got talent.



Phil

 

[Eric Schwartz]

[Often red gemstones are used to represent Ruby, but perhaps we should
consider a duck of some sort. Maybe even an ascii-art one we can drag
out for these occasions.]

(This was actually proposed a while ago, but we have been unable to find
a good picture without a copyright.)

There are tons of them on <URL:http://www.morguefile.com/>. I
particularly like
<URL:http://www.morguefile.com/archive/?display=1093204174425>, but
there are 144 results when searching for the word 'duck', so there are
likely to be more suitable ones.

-=Eric

 

[Nicholas Van Weerdenburg]

Finally, a thread on static versus dynamic typing in Ruby!
nikolai

Oh no, not another one.

Quick, duck! (or perhaps I should say, Super Duck (type) to the rescue!)

[Often red gemstones are used to represent Ruby, but perhaps we should
consider a duck of some sort. Maybe even an ascii-art one we can drag
out for these occasions.]

Phil

Hey- it also has good synergy with the penguin thing.

Rudy the Red Ruby Duck
Made Java Hacks Cluck
Now that's a language with Pluck!

 

[Lothar Scholz]

Hello gabriele,

gr> David A. Black ha scritto:

gr> I guess the type theorist out there would not agree (i.e. I'm told is
gr> easy to define Odd or Prime types in haskell). And even if agree that it
gr> may converge on what we have now, I still see a great value in crash
gr> early behaviour and documentation.
gr> I'm not the one to revolutionize ruby, I just want a slight enhancement

so why not add simply "assert_type" statements. Thats what python is
doing and doing well. It's about forcing the use not adding extra
syntax.

As a Tool writer i can tell you that many things could be done with this
optional type declaration.

It's just the chicken egg problem of Open Source Software:
No one wants to use it until they see an advantage and no one
writes something to show them the advantage.

 

[Lothar Scholz]

Hello David,


DGA> Koichi Sasada's talk on "YARV: Yet Another RubyVM" was interesting
DGA> in this regard:

DGA> http://www.atdot.net/yarv/RubyConf2004_YARV_pub.pdf

No. Can you please give me the slide number of the slide that has
anything to do with the type system ?

They are still one generation back with this Bytecode engine (at least what
is visible from this presentation). Good modern LISP systems
(like Franz Lisp, or Allegro) or the expensive SmallTalk compilers
are at the moment state of the art and they use typing hints.

YARV is to optimize the really bad implementation of the control flow
in ruby programs. It does not touch the type system in any way.

 

[gabriele renzi]

Lothar Scholz ha scritto:

gr> I guess the type theorist out there would not agree (i.e. I'm told is
gr> easy to define Odd or Prime types in haskell). And even if agree that it
gr> may converge on what we have now, I still see a great value in crash
gr> early behaviour and documentation.
gr> I'm not the one to revolutionize ruby, I just want a slight enhancement

so why not add simply "assert_type" statements. Thats what python is
doing and doing well. It's about forcing the use not adding extra
syntax.

As a Tool writer i can tell you that many things could be done with this
optional type declaration.

It's just the chicken egg problem of Open Source Software:
No one wants to use it until they see an advantage and no one
writes something to show them the advantage.

some python frameworks are doing it (zope, twisted, peak, actually most
anything 'enterprisish') but Guido still did not pronounced himself on
optional typing in python3k (IIRC he said it will be there, but is yet
unknown *how*).

Anyway, notice that I submitted RCR280 wich actually allow you to give
type assertions if you want them:

# if you want adaption:
def sum a,b
a=a.as Numeric; b=b.as Numeric
a+b
end

# if you want assertion:

def sum a,b
a.as Numeric; b.as Numeric
a+b
end

# if you don't care
def sum a,b
a+b
end

http://rcrchive.net/rcr/show/280

 

[Lothar Scholz]

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

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.

 

[David A. Black]

Hi --

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

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

 

[Nikolai Weibull]

<URL:http://www.morguefile.com/archive/?display=1093204174425>

I think that a rubber duck was what was wanted,
nikolai

 

[David G. Andersen]

DGA> Koichi Sasada's talk on "YARV: Yet Another RubyVM" was interesting
DGA> in this regard:

DGA> http://www.atdot.net/yarv/RubyConf2004_YARV_pub.pdf

No. Can you please give me the slide number of the slide that has
anything to do with the type system ?

You clipped my comment below that line that said "though he doesn't
explicitly discuss the type system."

YARV is interesting in regard to Ruby 2.0 in general.

-Dave