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

ruby-talk
1

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. :slight_smile:

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

Regards,

Dan

2

* Daniel Berger <djberg96@hotmail.com> [Nov 30, 2004 22:00]:

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

···

--
::: name: Nikolai Weibull :: aliases: pcp / lone-star / aka :::
::: born: Chicago, IL USA :: loc atm: Gothenburg, Sweden :::
::: page: www.pcppopper.org :: fun atm: gf,lps,ruby,lisp,war3 :::
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}

3

On Wed, Dec 01, 2004 at 05:57:47AM +0900, Daniel Berger scribed:

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:

"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:

  Ruby | zenspider.com | by ryan davis

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

···

--
work: dga@lcs.mit.edu me: dga@pobox.com
      MIT Laboratory for Computer Science http://www.angio.net/

4

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 :wink:

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

5

Daniel Berger wrote:

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.

6

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

···

On Wed, 1 Dec 2004 05:57:47 +0900, Daniel Berger <djberg96@hotmail.com> wrote:

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

--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca

7

Hi --

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 :wink:

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 :slight_smile:

David

···

On Wed, 1 Dec 2004, gabriele renzi wrote:

--
David A. Black
dblack@wobblini.net

8

In article <20041130210338.GC9390@puritan.pcp.ath.cx>,

···

Nikolai Weibull <mailing-lists.ruby-talk@rawuncut.elitemail.org> wrote:

* Daniel Berger <djberg96@hotmail.com> [Nov 30, 2004 22:00]:

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

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

9

Hello David,

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

  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.

···

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

10

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 :slight_smile:

<snip>

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!

11

David A. Black ha scritto:

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 :slight_smile:

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 :slight_smile:

12

* Phil Tomson <ptkwt@aracnet.com> [Dec 01, 2004 01:10]:

[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

···

--
::: name: Nikolai Weibull :: aliases: pcp / lone-star / aka :::
::: born: Chicago, IL USA :: loc atm: Gothenburg, Sweden :::
::: page: www.pcppopper.org :: fun atm: gf,lps,ruby,lisp,war3 :::
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}

13

Phil Tomson wrote:

In article <20041130210338.GC9390@puritan.pcp.ath.cx>,

* Daniel Berger <djberg96@hotmail.com> [Nov 30, 2004 22:00]:
   

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

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!

···

Nikolai Weibull <mailing-lists.ruby-talk@rawuncut.elitemail.org> wrote:

14

On Wed, Dec 01, 2004 at 09:40:16AM +0100, Lothar Scholz scribed:

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

> 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

···

--
work: dga@lcs.mit.edu me: dga@pobox.com
      MIT Laboratory for Computer Science http://www.angio.net/

15

Hi --

···

On Wed, 1 Dec 2004, gabriele renzi wrote:

David A. Black ha scritto:

>>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 :slight_smile:
>

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

--
David A. Black
dblack@wobblini.net

16

In article <20041201003620.GD9390@puritan.pcp.ath.cx>,

···

Nikolai Weibull <mailing-lists.ruby-talk@rawuncut.elitemail.org> wrote:

* Phil Tomson <ptkwt@aracnet.com> [Dec 01, 2004 01:10]:

[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

17

Nikolai Weibull <mailing-lists.ruby-talk@rawuncut.elitemail.org> writes:

* Phil Tomson <ptkwt@aracnet.com> [Dec 01, 2004 01:10]:

[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:Morguefile.com free photographs for commercial use.. I
particularly like
<URL:Morguefile.com free photographs for commercial use., but
there are 144 results when searching for the word 'duck', so there are
likely to be more suitable ones.

-=Eric

···

--
Come to think of it, there are already a million monkeys on a million
typewriters, and Usenet is NOTHING like Shakespeare.
    -- Blair Houghton.

18

Hello gabriele,

David A. Black ha scritto:

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 :slight_smile:

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 :slight_smile:

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.

···

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

19

Lothar Scholz 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). 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 :slight_smile:

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

20

* Eric Schwartz <emschwar@fc.hp.com> [Dec 01, 2004 12:40]:

<URL:Morguefile.com free photographs for commercial use.;

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

···

--
::: name: Nikolai Weibull :: aliases: pcp / lone-star / aka :::
::: born: Chicago, IL USA :: loc atm: Gothenburg, Sweden :::
::: page: www.pcppopper.org :: fun atm: gf,lps,ruby,lisp,war3 :::
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}