# A mechanism for specifying static type signatures (NOT STATIC TYPING) **URL:** \ **Category:** ruby-talk\ **Created:** [30 September 2007 08:30 UTC](https://rubytalk.org/t/a-mechanism-for-specifying-static-type-signatures-not-static-typing/41050 "2007-09-30T08:30:30Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![Charles\_Oliver\_Nutte](https://avatars.discourse-cdn.com/v4/letter/c/71e660/32.png) [@Charles\_Oliver\_Nutte](https://rubytalk.org/u/Charles_Oliver_Nutte)\ **Post date:** [30 September 2007 08:30 UTC](https://rubytalk.org/t/a-mechanism-for-specifying-static-type-signatures-not-static-typing/41050/1 "2007-09-30T08:30:30Z")
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 {\ =\> [\, \ ...]} 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 ---
**Author:** ![Konrad\_Meyer](https://avatars.discourse-cdn.com/v4/letter/k/df705f/32.png) [@Konrad\_Meyer](https://rubytalk.org/u/Konrad_Meyer)\ **Post date:** [30 September 2007 09:03 UTC](https://rubytalk.org/t/a-mechanism-for-specifying-static-type-signatures-not-static-typing/41050/2 "2007-09-30T09:03:01Z")
Quoth Charles Oliver Nutter: > 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: > > [Headius: The Compiler Is Complete](http://headius.blogspot.com/2007/09/compiler-is-complete.html) > > 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 > > {\ =\> [\, \ ...]} > > 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 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, > **···** > > -- > Konrad Meyer \ [http://konrad.sobertillnoon.com/](http://konrad.sobertillnoon.com/) ---
**Author:** ![a11](https://yyz1.discourse-cdn.com/flex029/user_avatar/rubytalk.org/a11/32/8169_2.png) [@a11](https://rubytalk.org/u/a11)\ **Post date:** [30 September 2007 15:47 UTC](https://rubytalk.org/t/a-mechanism-for-specifying-static-type-signatures-not-static-typing/41050/3 "2007-09-30T15:47:43Z")
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/) > **···** > > On Sep 30, 2007, at 2:30 AM, Charles Oliver Nutter wrote: > > > 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: > > > > [Headius: The Compiler Is Complete](http://headius.blogspot.com/2007/09/compiler-is-complete.html) > > > > 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 > > > > {\ =\> [\, \ ...]} > > > > 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? > > -- > we can deny everything, except that we have the possibility of being better. simply reflect on that. > h.h. the 14th dalai lama ---
**Author:** ![ThoML](https://avatars.discourse-cdn.com/v4/letter/t/d78d45/32.png) [@ThoML](https://rubytalk.org/u/ThoML)\ **Post date:** [30 September 2007 16:50 UTC](https://rubytalk.org/t/a-mechanism-for-specifying-static-type-signatures-not-static-typing/41050/4 "2007-09-30T16:50:04Z")
> 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. > {\ =\> [\, \ ...]} 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: > **···** > > > [Integer, Array, String] > > def mymethod(i, a) ... ---
**Author:** ![Rick\_DeNatale1](https://avatars.discourse-cdn.com/v4/letter/r/bbce88/32.png) [@Rick\_DeNatale1](https://rubytalk.org/u/Rick_DeNatale1)\ **Post date:** [2 October 2007 17:34 UTC](https://rubytalk.org/t/a-mechanism-for-specifying-static-type-signatures-not-static-typing/41050/5 "2007-10-02T17:34:18Z")
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. > **···** > > On 9/30/07, Charles Oliver Nutter \ wrote: > > > 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: > > > > [Headius: The Compiler Is Complete](http://headius.blogspot.com/2007/09/compiler-is-complete.html) > > > > 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 > > > > {\ =\> [\, \ ...]} > > > > 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? > > -- > Rick DeNatale > > My blog on Ruby > [http://talklikeaduck.denhaven2.com/](http://talklikeaduck.denhaven2.com/)