# A mechanism for specifying static type signatures (NOT STATIC TYPING)

**URL:** <https://www.ruby-forum.com/t/a-mechanism-for-specifying-static-type-signatures-not-static-typing/115919>\
**Category:** Ruby\
**Created:** [September 30, 2007, 10:31am UTC](https://www.ruby-forum.com/t/a-mechanism-for-specifying-static-type-signatures-not-static-typing/115919 "2007-09-30T10:31:02Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![headius](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/7c8e57/32.png) [@headius](https://www.ruby-forum.com/u/headius)\
**Post date:** [September 30, 2007, 10:31am UTC](https://www.ruby-forum.com/t/a-mechanism-for-specifying-static-type-signatures-not-static-typing/115919/1 "2007-09-30T10:31:02Z")

</div>

JRuby’s main compiler is complete, so I’m starting to kick around ideas  
for a second compiler.

The goal of the second compiler would be to produce normal-looking Java  
classes that are actually just Ruby code underneath. Constructing them  
in the normal Java way would invoke initialize; calling methods in the  
normal Java way would dynamically call the associated method.

I talk about it in the second half of this post:

> **[The Compiler Is Complete](http://headius.blogspot.com/2007/09/compiler-is-complete.html)**
>
> It is a glorious day in JRuby-land, for the compiler is now complete. Tom and I have been traveling in Europe the past two weeks, first for ...

Now before anyone cries foul, this is not about adding static typing to  
Ruby; it’s about finding a way to specify what types should be inserted  
into the generated Java class to make things easy on the Java side,  
while avoiding incompatible changes to JRuby.

Since so many of you have a better perception of beauty in DSL-like  
syntaxes than I do, I figured you might have a good suggestion.

The first version I proposed on the blog would be a simple map in the  
class body of the form

{ =\> [\<arg type 1\>, \<arg type 2\> …]}

as in

{String =\> [Integer, Array]}  
def mymethod(i, a) …

which would appear to Java code as

public String mymethod(Integer i, List a) { …

or perhaps

public String mymethod(int i, List a) { …

But I know it’s not particularly pretty. So here’s the requirements:

- provide a way to specify the types of an immediately-following method  
definition; this is only going to be a compiler hint, so it doesn’t have  
to (and perhaps should avoid) having any side-effects.
- have no lasting side-effects when run nomally. The above code would  
just produce a hash that gets immediately thrown away if run in e.g.  
Matz’s Ruby.
- not require any syntactic or library changes to Ruby, so the same code  
can run unmodified on any implementation.

Ideas?

- Charlie

---

<div class="post-metadata">

**Author:** ![headius](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/7c8e57/32.png) [@headius](https://www.ruby-forum.com/u/headius)\
**Post date:** [September 30, 2007, 11:03am UTC](https://www.ruby-forum.com/t/a-mechanism-for-specifying-static-type-signatures-not-static-typing/115919/2 "2007-09-30T11:03:46Z")

</div>

Quoth Charles Oliver N.:

> [http://headius.blogspot.com/2007/09/compiler-is-complete.html](http://headius.blogspot.com/2007/09/compiler-is-complete.html)  
> class body of the form  
> public String mymethod(Integer i, List a) { …
> 
> - have no lasting side-effects when run nomally. The above code would  
> just produce a hash that gets immediately thrown away if run in e.g.  
> Matz’s Ruby.
> - not require any syntactic or library changes to Ruby, so the same code  
> can run unmodified on any implementation.
> 
> Ideas?
> 
> - Charlie

I rather like Okke’s suggestion to use method name / argument name  
hints.  
ex:  
Ruby:  
def str\_my\_method(int\_blah, ary\_bar)  
end

Java:  
String my\_method(int blah, List bar){  
}

or so.

But if you’re sticking with a Hash preceding the method, I think a  
better  
order would be {[Integer, Array] =\> String} (as mentioned by someone’s  
comment on your blog).

Thanks a bunch,

---

<div class="post-metadata">

**Author:** ![headius](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/7c8e57/32.png) [@headius](https://www.ruby-forum.com/u/headius)\
**Post date:** [September 30, 2007, 5:48pm UTC](https://www.ruby-forum.com/t/a-mechanism-for-specifying-static-type-signatures-not-static-typing/115919/3 "2007-09-30T17:48:29Z")

</div>

On Sep 30, 2007, at 2:30 AM, Charles Oliver N. wrote:

> The first version I proposed on the blog would be a simple map in
> 
> doesn’t have to (and perhaps should avoid) having any side-effects.
> 
> - have no lasting side-effects when run nomally. The above code  
> would just produce a hash that gets immediately thrown away if run  
> in e.g. Matz’s Ruby.
> - not require any syntactic or library changes to Ruby, so the same  
> code can run unmodified on any implementation.
> 
> Ideas?

my thoughts are that this will lead to other enhancements - compiler  
hints - so why not invent some sort of unifying syntax up front as  
other compilers have. for instance

pragma :mymethod do |m|  
m[String, Array] =\> String  
m[Integer, Array] =\> Integer  
end

so this is specifying two signatures for a polymorphic method. of  
course you’d have a shortcut

signature :mymethod, [String, Array] =\> Integer

extending the building method class for this is very appealing

Method(:mymethod).pragma do  
map [String, Array] =\> String,  
[Integer, Array] =\> Integer  
end

where to block above is defined thusly

class Method  
def pragma &block  
(( @pragma ||= Pragma.new self )).configure &block  
end

class Pragma  
def initialize method  
@method = method  
@signatures = []  
@dsl = DSL.new self  
end

```
 class DSL
   def initialize pragma
     @pragma = pragma
   end

   def configure &block
     instance_eval &block
   end

   def map sig = {}
     sig.each do |argv, returned|
       @pragma.signatures << [argv, returned]
     end
   end
 end

```

end  
end

i like the idea of sticking it into Method and pulling the DSL out in  
it’s own namespace for the instance\_eval lets you have a really  
powerful syntax. for instance this can work:

Method(:mymethod).pragma do  
map variardic =\> void  
end

simply by

class Module  
class Pragma  
class DSL  
( VARIARDIC = Object.new ).freeze  
( VOID = Object.new ).freeze  
def variardic() VARIARDIC end  
def void() VOID end  
end  
end  
end

it’s unrelated, but you might one or two idea from this:

[http://codeforpeople.com/lib/ruby/parseargs/parseargs-0.3.0/README](http://codeforpeople.com/lib/ruby/parseargs/parseargs-0.3.0/README)

it’s bit rotted a bit, but at one time i put a bit of thought into  
what the various types of ruby arglists could be and how to manage  
that compactly.

keep up the good work on jruby.

cheers.

a @ [http://drawohara.com/](http://drawohara.com/)

---

<div class="post-metadata">

**Author:** ![headius](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/7c8e57/32.png) [@headius](https://www.ruby-forum.com/u/headius)\
**Post date:** [September 30, 2007, 6:51pm UTC](https://www.ruby-forum.com/t/a-mechanism-for-specifying-static-type-signatures-not-static-typing/115919/4 "2007-09-30T18:51:11Z")

</div>

> Now before anyone cries foul, this is not about adding static typing to  
> Ruby

If it provides hints for the compiler to cry on obvious errors, I  
don’t care what people call it.

> { =\> [\<arg type 1\>, \<arg type 2\> …]}

I find it rather confusing that the return value is in front of the  
argument list. Why not:

> args Integer, Array, String  
> def mymethod(i, a) …

The last one is the return value. I think Haskell uses a somewhat  
similar notation: f :: a -\> b -\> c

This could be implemented as a class method that does nothing in  
normal  
ruby. This could be called a library change though.

Otherwise:

---

<div class="post-metadata">

**Author:** ![headius](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/7c8e57/32.png) [@headius](https://www.ruby-forum.com/u/headius)\
**Post date:** [October 2, 2007, 7:35pm UTC](https://www.ruby-forum.com/t/a-mechanism-for-specifying-static-type-signatures-not-static-typing/115919/5 "2007-10-02T19:35:11Z")

</div>

On 9/30/07, Charles Oliver N. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> [http://headius.blogspot.com/2007/09/compiler-is-complete.html](http://headius.blogspot.com/2007/09/compiler-is-complete.html)  
> class body of the form  
> public String mymethod(Integer i, List a) { …
> 
> - have no lasting side-effects when run nomally. The above code would  
> just produce a hash that gets immediately thrown away if run in e.g.  
> Matz’s Ruby.
> - not require any syntactic or library changes to Ruby, so the same code  
> can run unmodified on any implementation.
> 
> Ideas?

The only thing that I can think of which is guaranteed to meet all  
three requirements is some kind of pragma syntax which is a comment to  
other implementations:

# @@javatype String(Integer, List)

Anything which relies on executable Ruby code to express pragmas risks  
running afoul of SOME DSL or another.

–  
Rick DeNatale

My blog on Ruby  
[http://talklikeaduck.denhaven2.com/](http://talklikeaduck.denhaven2.com/)
