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

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:

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

{<return type> => [<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

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

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

{<return type> => [<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

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 <konrad@tylerc.org> http://konrad.sobertillnoon.com/

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

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/

···

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

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

{<return type> => [<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?

--
we can deny everything, except that we have the possibility of being better. simply reflect on that.
h.h. the 14th dalai lama

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.

{<return type> => [<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:

···

[Integer, Array, String]
def mymethod(i, a) ...

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 <charles.nutter@sun.com> 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

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

{<return type> => [<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?

--
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/